Stockage

La zone Storage gère deux types de ressources. Une connexion de stockage enregistre l’accès à un stockage objet ou de fichiers qui s’exécute ailleurs. Le stockage managé est un stockage objet compatible S3 qu’Opfield provisionne et exécute sur un nœud Storage ; les nouveaux clusters utilisent SeaweedFS. Les deux nécessitent Personal ou supérieur. Les ressources de stockage servent de destinations pour les sauvegardes de bases de données, et le stockage managé peut donner aux charges de travail un accès privé limité à certains buckets.

Question	Connexion de stockage	Stockage managé
Qui exploite le service	Le fournisseur ou votre équipe de stockage	Opfield, sous forme de SeaweedFS sur un nœud Storage avec un disque borné, ou sur plusieurs en Business et Enterprise
Protocoles	S3 (AWS S3, Cloudflare R2, MinIO, autres services compatibles S3), SFTP, FTP, FTPS	S3
Explorateur d’objets	Oui	Oui
Destination de sauvegarde	Oui	Oui
Clés d’accès et liens de charges de travail	Non	Oui
Exposition publique	Sans objet	Privé par défaut ; un écouteur S3 public est facultatif
Suppression	Retire uniquement la connexion enregistrée par Opfield	Retire le service et efface ses données

Connexions de stockage

Sélectionnez Add Storage et choisissez un fournisseur :

Fournisseur	Détails de connexion
AWS S3, Cloudflare R2, MinIO, Other (S3-compatible)	Région, identifiant de clé d’accès et clé d’accès secrète ; un point de terminaison pour tout sauf AWS ; jeton de session, bucket par défaut et adressage path-style facultatifs (activé par défaut pour MinIO)
SFTP	Hôte, port (22 par défaut), nom d’utilisateur, mot de passe ou clé privée avec une phrase secrète facultative, et l’SSH host key fingerprint SHA-256 du serveur, obligatoire et vérifiée à chaque connexion
FTP, FTPS	Hôte, port (21, ou 990 pour le FTPS implicite), nom d’utilisateur et mot de passe ; FTPS prend en charge le mode explicite ou Implicit TLS et vérifie toujours le certificat du serveur avec le magasin de confiance du système ou un CA Certificate que vous fournissez

Pour FTP, FTPS et SFTP, les répertoires situés sous le Base Path configuré apparaissent comme des buckets. SMB n’est pas pris en charge.

Pour modifier une connexion enregistrée, ouvrez Storage Settings sur sa page. Test connection, en bas de la boîte de dialogue, vérifie la connexion enregistrée et indique le temps de réponse ; Save Changes enregistre le formulaire.

Opfield stocke chiffrés les secrets, les empreintes de clés d’hôte et les certificats de CA, et ne renvoie jamais de secrets dans le formulaire : laisser un champ secret vide conserve la valeur stockée, mais modifier le point de terminaison, l’hôte, le nom d’utilisateur, le protocole ou les paramètres de confiance exige de ressaisir le secret. L’affichage des identifiants enregistrés nécessite storage:credentials:reveal. storage:credentials:use permet aux sauvegardes de bases de données et aux tâches de copie d’utiliser les identifiants enregistrés sans les afficher. Un bucket auquel des politiques ou un historique de sauvegardes font référence ne peut pas être supprimé ; pour les connexions de stockage, voir Supprimer un stockage auquel des sauvegardes font référence.

L’onglet Objects parcourt les buckets et les objets, ouvre et modifie des fichiers, téléverse des fichiers, crée des dossiers et supprime des fichiers et des dossiers. Il n’est pas disponible tant que le stockage est hors ligne. La création d’un bucket apparaît lorsqu’une connexion n’a aucun bucket et nécessite storage:objects:admin. L’API permet en plus de supprimer des buckets et de créer des liens de téléchargement présignés ; les liens présignés ne sont pas disponibles pour le stockage managé privé, qui doit être téléchargé via Opfield, ni pour FTP, FTPS et SFTP. Demander un objet ou un bucket qui n’existe pas renvoie STORAGE_NOT_FOUND. Voir Permissions.

Les clients MCP transfèrent les objets volumineux sans base64 dans les appels d’outils : download_storage_object vérifie storage:objects:read et renvoie un lien à usage unique, valable 15 minutes, accompagné d’une commande curl prête à l’emploi qui transmet l’objet en flux via Opfield, et upload_storage_object téléverse par fragments qu’Opfield vérifie. Un lien de téléchargement est revérifié par rapport aux permissions actuelles du propriétaire au moment de son utilisation et ne fonctionne qu’une fois.

Stockage objet managé

Choisissez Deploy managed storage pour provisionner un stockage objet sur un nœud Storage, éventuellement dans un dossier de stockage ; le sélecteur de dossier ne propose que les dossiers dans lesquels vous pouvez créer du stockage. Les nouveaux clusters exécutent SeaweedFS 4.47, épinglé sur une empreinte d’image immuable ; il n’y a pas de changement de version sur place. Le nœud Storage récupère le build de SeaweedFS 4.47 propre à Opfield depuis GitHub Container Registry (ghcr.io) ; s’il n’y parvient pas, il utilise l’image amont, d’abord depuis le miroir d’Opfield sur ghcr.io, puis depuis Docker Hub, en vérifiant son empreinte dans les deux cas. Si aucune source ne fonctionne, le provisionnement s’arrête avec MANAGED_STORAGE_IMAGE_PULL_FAILED.

Un cluster s’exécute sur un nœud Storage. En Business et Enterprise, il peut aussi s’exécuter sur 2 à 5 nœuds Storage avec un primaire et des copies qui prennent le relais en cas de perte ; voir Bases de données et stockage sur plusieurs serveurs. Définissez les limites de CPU, de mémoire (au moins 512 Mio) et de disque lors du provisionnement ; la Console plafonne le disque à l’espace libre du nœud moins sa réserve. Le disque est une image bornée et préallouée sur le nœud Storage, comme le stockage des bases de données managées : chaque cluster y occupe un périphérique loop, et le démon Docker ne démarre le moteur qu’une fois cette image montée ; voir Détails pour l’opérateur : stockage et TLS direct. Opfield génère les identifiants root, et leur affichage nécessite storage:credentials:reveal.

Après le provisionnement, vous pouvez modifier le nom, les tags, le CPU, la mémoire, le swap, la taille du disque et la publication S3. Le disque ne peut qu’augmenter, et une modification est refusée tant qu’une précédente est encore en cours d’application. L’agrandissement du disque, ainsi que l’activation ou la désactivation de la publication ou la modification de son port, recréent le conteneur de stockage ; les données et les clés sont conservées. Restart et la relance d’un provisionnement en échec sont aussi disponibles.

Les noms de stockages managés sont uniques sur chaque nœud Storage. Créer ou renommer un stockage managé avec un nom déjà utilisé par un autre stockage managé sur le même nœud échoue avec 409 MANAGED_STORAGE_NAME_IN_USE ; lorsque cet autre stockage n’a pas pu être provisionné, relancez-le ou supprimez-le d’abord. Un nom redevient libre dès que la suppression de son stockage commence. Lors de la mise à jour d’Opfield vers 2.11, les clusters plus récents qui partageaient un nom sur un même nœud ont été renommés avec le premier suffixe libre -2, -3, …, ainsi que leur connexion de stockage ; voir Conflits résolus par la mise à jour 2.11.

Le stockage managé est privé par défaut. Opfield le joint via des routes Relay authentifiées. Vous pouvez activer explicitement des chemins d’accès supplémentaires :

• Publish S3 endpoint expose l’API S3 sur un port de l’hôte, 9000 par défaut.
• TLS chiffre le point de terminaison S3 avec un certificat de l’Opfield Storage CA. Il se choisit à la création du cluster et ne peut pas être activé plus tard. Les clients doivent faire confiance à cette CA : la boîte de dialogue des identifiants affiche son empreinte SHA-256 et permet de la télécharger sous le nom storage-ca.pem ou de la copier. Via l’API, GET /api/managed-storage/{id}/ca-certificate renvoie le certificat et l’empreinte à toute personne qui peut consulter le cluster, ou MANAGED_STORAGE_TLS_DISABLED (409) lorsque TLS est désactivé ; l’outil MCP manage_managed_storage propose la même chose avec l’action ca_certificate.

Les clusters SeaweedFS ne proposent que S3 ; ils n’ont pas d’écouteurs FTP ni SFTP.

Les sauvegardes de bases de données et les tâches de copie joignent le stockage managé via un écouteur local et vérifient son certificat en tant que localhost ou 127.0.0.1. Opfield ajoute automatiquement ces noms aux certificats des clusters créés avec une version antérieure. Pendant l’application du nouveau certificat, les sauvegardes attendent dans la file en affichant la raison et réessaient d’elles-mêmes ; elles n’échouent avec BACKUP_STORAGE_CERTIFICATE_OUTDATED que si le certificat n’est pas servi dans les 7 heures. Opfield ne modifie pas les pare-feu des hôtes. N’ouvrez que les ports dont a besoin un client identifié.

Renouvellement des certificats TLS

Opfield renouvelle automatiquement le certificat d’un cluster TLS, en vérifiant toutes les heures : lorsque les deux tiers de sa durée de vie sont écoulés, qu’il reste 30 jours ou moins, qu’un nom requis manque ou que le certificat provient d’une autre CA. Le démon du nœud Storage écrit le nouveau certificat et le moteur le recharge sans redémarrage ; Opfield ne bascule dessus qu’une fois que le cluster le sert. La Storage CA ne change pas ; les clients continuent donc de fonctionner.

• Les Connection Details du stockage affichent une ligne discrète TLS Certificate avec la date d’expiration et soit « renewed automatically », soit « needs attention ». Un avis n’apparaît sur la page que lorsqu’une intervention est nécessaire — renouvellement en échec, 7 jours ou moins restants, certificat renouvelé pas encore chargé, renouvellement en attente du démon du nœud, ou durée de vie limitée par la CA —, avec la raison, la date d’expiration et Renew now pour les utilisateurs autorisés à modifier le stockage. Le tableau de bord liste aussi chaque stockage managé et chaque base de données managée dont le certificat nécessite une intervention et que vous pouvez consulter. Via l’API et MCP, vous pouvez renouveler à tout moment.
• Un redémarrage n’est utilisé que lorsqu’il reste 7 jours ou moins, lorsque vous l’autorisez lors d’un renouvellement manuel, ou lorsque vous renouvelez manuellement sur un nœud dont le démon ne peut pas encore recharger les certificats. Sinon, un tel nœud conserve le certificat actuel jusqu’à la mise à jour de son démon.
• Les clusters SeaweedFS créés avant 2.11 ne relisent leurs fichiers de certificats que toutes les quelques heures ; un renouvellement peut donc mettre autant de temps à être servi ; autorisez un redémarrage pour l’appliquer plus tôt.
• Tant que le renouvellement continue d’échouer, Opfield déclenche l’événement de notification Managed Service Certificate Renewal Failed, qui disparaît après un renouvellement réussi. Créez une règle d’alerte pour cet événement. Les renouvellements sont enregistrés dans le journal d’audit.
• API : GET /api/managed-storage/{id}/certificate et POST /api/managed-storage/{id}/certificate/renew avec allowRestart facultatif ; MCP et assistant : actions certificate_status et renew_certificate de manage_managed_storage. Le renouvellement nécessite storage:edit et continue de fonctionner après la fin d’une période de grâce de licence.

Capacité

Chaque bucket est stocké dans au moins un volume de données qui lui est propre, et Opfield dimensionne les volumes à partir du disque ; prévoyez donc environ un volume de données par bucket et préférez un nombre modéré de buckets. Lorsque le disque est plein, les écritures échouent avec HTTP 500 tandis que les objets existants restent lisibles ; libérez de l’espace en supprimant des objets, ou agrandissez le disque dans les paramètres, ce qui recrée le conteneur, et les écritures reprennent.

Clés d’accès et liens de charges de travail

Sur la page de détail du stockage, l’onglet IAM Keys émet des identifiants S3 avec un nom facultatif, un accès en lecture seule ou en lecture-écriture, jusqu’à 64 buckets (aucun signifie tous les buckets) et une expiration facultative. Chaque clé est son propre principal IAM dans le moteur, limité à ses buckets : elle ne peut lister que ces buckets, lire des objets et — avec un accès en lecture-écriture — écrire et supprimer des objets, mais elle ne peut ni créer ni supprimer de buckets. Le moteur applique lui-même l’expiration, et la révocation d’une clé supprime immédiatement son principal. La clé secrète n’est affichée qu’une fois, à la création de la clé. La création et la révocation de clés nécessitent storage:iam.

La boîte de dialogue des identifiants affiche des commandes de démarrage rapide pour AWS CLI et rclone. Pour un cluster TLS, elles passent la CA téléchargée sous la forme --ca-bundle storage-ca.pem (AWS CLI) ou --ca-cert storage-ca.pem (rclone). Avec une clé limitée à des buckets, rclone a besoin de no_check_bucket = true (inclus dans le démarrage rapide) ; sinon, il tente de créer le bucket et échoue avec 403.

Un lien de stockage managé donne à un Container ou à un Deployment un accès privé à 1 à 32 buckets. Ajoutez-le depuis l’onglet Environment de la charge de travail ; les services Compose ne sont pas pris en charge. Opfield émet une clé limitée à ces buckets, rattache la charge de travail à un petit réseau privé propre au lien, servi par le connecteur secure-link partagé de son nœud Docker, et stocke les valeurs comme secrets gérés dans des variables d’environnement nommées par défaut S3_ENDPOINT, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, S3_BUCKET (le premier bucket) et AWS_REGION. La clé ne peut atteindre que les buckets listés ; une charge de travail compromise ne peut donc pas lire le reste du stockage. Les buckets listés par le lien qui n’existent pas encore sont créés à la création du lien, car la clé propre au lien ne peut pas les créer. La création d’un lien nécessite storage:bind (inclus dans storage:iam) et la permission de modifier l’environnement et les secrets de la charge de travail ; un lien sur un Deployment nécessite aussi docker:containers:manage sur celui-ci, plus docker:containers:edit lorsqu’il modifie l’environnement du Deployment.

Un lien n’a pas de limite de connexions fixe : l’admission Relay le borne selon la charge et partage équitablement la capacité entre les routes, et les connexions inactives des pools restent ouvertes. La vue d’ensemble de la charge de travail affiche l’exécution du lien à côté de ses liens de bases de données. Voir Capacité des liens et pools de connexions.

À partir de 2.11.1, les liens de stockage s’exécutent sur le connecteur partagé, comme les liaisons de bases de données et les liens entre conteneurs, sans conteneur connecteur par lien. Un lien créé avant 2.11.1 bascule sur celui-ci après la mise à jour du démon Docker de la charge de travail, et Opfield recrée une fois la charge de travail liée juste après la bascule : un Deployment se déploie en blue/green sans interruption, un Container redémarre une fois. Les liens créés en 2.11.1 ne nécessitent pas de recréation. Revenir au démon Docker 2.11.0 rebascule les liens de lui-même, là encore avec une recréation par charge de travail.

La charge de travail n’a pas besoin de s’exécuter : un lien peut cibler un Container ou un Deployment arrêté, qui redémarre en boucle, en échec ou pas encore déployé, et Opfield l’enregistre sans attendre la charge de travail. Tant que la charge de travail ne s’exécute pas avec le lien, celui-ci apparaît comme pending (observedState: "target_applied" dans l’API et MCP) ; il devient actif au prochain démarrage de la charge de travail ou à la fin de son déploiement en cours, et la relance d’un build Git en échec le déploie. Via l’API, MCP ou l’assistant, un Container à source Git peut aussi être lié par son nom avant son premier build, qui le démarre alors avec le lien. Un retour arrière ou une bascule de slot de Deployment conserve les liens actuels. Le nœud Docker de la charge de travail doit être en ligne.

Pour la configuration nginx avancée, une Route peut aussi utiliser une liaison Secure Link supplémentaire vers un stockage objet managé prêt, sans réseau Docker partagé ni port S3 publié ; les clients ont toujours besoin d’identifiants S3. Un stockage managé ne peut pas être l’upstream principal d’une Route. La création de la liaison nécessite le droit de modifier la Route et de consulter le stockage ; voir Upstreams sécurisés.

La suppression d’un stockage managé efface ses données et retire automatiquement ses liens de charges de travail. Elle est refusée tant que des liaisons Secure Link de Routes ou une tâche de copie active y font référence, et les références des sauvegardes sont traitées comme décrit ci-dessous.

Les réseaux du stockage géré par Opfield (opfield-storage-* ; gateway-storage-* pour les réseaux créés avant 2.12.1) sont masqués des actions sur les réseaux Docker : les utilisateurs ne peuvent ni y connecter ou en déconnecter des conteneurs, ni supprimer ces réseaux, ni y créer des conteneurs.

Copier des données entre stockages

Une tâche de copie copie des objets côté serveur d’un stockage S3 vers un autre, managé ou externe — par exemple d’un ancien cluster MinIO vers SeaweedFS, ou d’un bucket externe vers un stockage managé. Les tâches de copie n’ont pas d’écran dans la Console : lancez-les depuis l’assistant intégré, MCP ou l’API REST.

• Modes : copy ajoute et écrase des objets et ne supprime jamais. sync supprime aussi les objets de destination que la source ne possède pas ; ne l’utilisez que pour une passe finale délibérée. dryRun n’écrit rien et indique ce qui diffère.
• Destinations actives : un sync vers un stockage managé encore utilisé par des liens de charges de travail ou des clés d’accès en écriture, et dont les écritures ne sont pas gelées, est refusé avec STORAGE_COPY_DESTINATION_LIVE, car il pourrait supprimer des objets écrits par ces clients. Gelez les écritures de la destination, utilisez copy, ou passez allowLiveDestination: true si vous acceptez ce risque.
• Buckets : "all" ou une liste de noms. Chaque bucket conserve son nom sur la destination. Les buckets de destination manquants sont créés lorsque vous détenez storage:objects:admin sur la destination ; passez createBuckets: false pour exiger des buckets existants. Le versionnage des buckets, les règles de cycle de vie et les politiques de buckets ne sont pas copiés.
• Exécution : l’exécuteur de sauvegardes d’un nœud Storage transfère les objets en flux avec rclone, en préservant les métadonnées des objets comme le type de contenu, puis compare les deux côtés. Opfield choisit un nœud Storage en ligne dont le démon prend en charge les tâches de copie, ou vous en choisissez un avec executorNodeId. Le stockage managé privé est joint via des routes Relay propres à chaque tâche ; aucun port n’est donc publié et aucun conteneur n’est recréé. Les identifiants restent à l’intérieur d’Opfield et de l’exécuteur. limits facultatifs : timeoutSeconds (par défaut un jour, au plus sept), cpuCores, memoryMb et transfers.
• Rapport de vérification : une tâche terminée indique, par bucket et au total, le nombre d’objets et d’octets des deux côtés, le nombre d’objets manquants, différents et (pour sync) en trop avec des exemples de clés, ainsi que clean. Seule une tâche terminée avec clean: true prouve la copie ; une tâche terminée peut encore signaler des différences, par exemple des objets écrits par des clients pendant son exécution. Relancer la même tâche ne transfère que ce qui a changé, et inverser la source et la destination recopie dans l’autre sens.
• Limites : une seule tâche active peut écrire dans un stockage, aucune tâche ne peut lire un stockage dans lequel une autre tâche écrit, et un exécuteur exécute au plus deux tâches de copie à la fois.

Action	API REST	MCP et assistant
Lancer une tâche	POST /api/storage/copy-jobs avec sourceStorageId, destinationStorageId, buckets, mode, dryRun, et éventuellement createBuckets, allowLiveDestination, executorNodeId et limits	manage_storage_connection copy_data_start
Suivre une tâche et lire son rapport	GET /api/storage/copy-jobs/{id}	copy_data_status
Lister les tâches	GET /api/storage/copy-jobs	copy_data_list
Annuler une tâche	POST /api/storage/copy-jobs/{id}/cancel	copy_data_cancel

Les tâches de copie prennent des identifiants de connexions de stockage. Pour un stockage managé, utilisez l’identifiant de sa connexion de stockage (objectStorageConnectionId dans les détails du stockage managé renvoyés par l’API et MCP), et non l’identifiant du stockage managé.

Une tâche annulée ou ayant dépassé son délai ne laisse jamais de conteneur d’exécution derrière elle, et son état final est enregistré avant d’être signalé ; il survit donc à un redémarrage du démon juste après.

Le lancement d’une tâche nécessite storage:objects:read et storage:credentials:use sur la source, storage:objects:write et storage:credentials:use sur la destination, et nodes:backups:execute sur le nœud exécuteur. Opfield revérifie les permissions du propriétaire de la tâche lorsqu’il la distribue. Le lancement d’une tâche nécessite un plan Personal ou supérieur en cours de validité ; le suivi, la liste et l’annulation des tâches continuent de fonctionner après la fin d’une période de grâce de licence.

Migrer depuis MinIO

MinIO n’est plus distribué par son éditeur ; les nouveaux stockages managés exécutent donc SeaweedFS. Les clusters MinIO managés créés avec des versions antérieures continuent de fonctionner en tant que moteur hérité et sont signalés Legacy MinIO engine dans la Console :

• Ils continuent de servir S3, leurs clés d’accès, leurs liens de charges de travail, leurs liaisons Secure Link et leurs éventuels écouteurs FTP ou SFTP, et les opérations courantes se poursuivent tant que l’image MinIO est encore présente sur le nœud Storage.
• De nouveaux clusters MinIO ne peuvent pas être créés.
• Une opération qui doit recréer le conteneur et donc récupérer l’image — par exemple modifier la publication, agrandir le disque ou rétablir un conteneur perdu — échoue avec MANAGED_STORAGE_ENGINE_IMAGE_UNAVAILABLE si l’image n’est plus sur le nœud, car elle ne peut plus être téléchargée. Opfield le signale avant de toucher au conteneur ou à ses données.

Migrer avec l’assistant

Il n’existe pas de bouton de migration. Pour faire passer un cluster à SeaweedFS, demandez-le à l’assistant intégré, par exemple : Migre le stockage managé « files » de MinIO vers SeaweedFS. L’assistant suit pas à pas le guide de migration d’Opfield, rend compte du résultat de chaque étape et demande confirmation avant la bascule et avant de mettre hors service le cluster MinIO. Il agit avec vos permissions ; vous avez donc besoin des scopes listés dans Actions de migration. Un client MCP comme Codex ou Claude Code peut exécuter la même migration avec les mêmes outils.

1. Vérification préalable (lecture seule). L’assistant vérifie que le cluster est prêt, liste ses buckets, l’espace utilisé, les clés d’accès, les liens de charges de travail, les Secure Links ainsi que les politiques et l’historique de sauvegardes, et vérifie que le nœud cible dispose d’au moins 1,2 fois l’espace utilisé en libre et d’un démon à jour. Il s’arrête si le cluster utilise FTP ou SFTP, que SeaweedFS ne propose pas.
2. Construire la cible. Il crée un cluster SeaweedFS, privé par défaut. Sur demande, il réutilise les identifiants root de MinIO afin que les clients qui les utilisent continuent de fonctionner.
3. Copier en ligne. Une tâche de copie copie chaque bucket pendant que les applications continuent d’écrire dans MinIO. Le rapport peut montrer des différences tant que des clients écrivent ; la copie est donc répétée jusqu’à ce que seuls des objets récents diffèrent ; chaque exécution ne transfère que ce qui a changé.
4. Basculer. Les écritures sont suspendues pendant une courte fenêtre ; les lectures continuent de fonctionner.
   • Déplacer d’abord les sauvegardes : les politiques de sauvegarde qui écrivent dans le cluster MinIO sont déplacées vers le nouveau cluster, ou suspendues si vous le préférez, et les tâches de sauvegarde et de restauration en cours qui l’utilisent doivent se terminer ou être annulées.
   • Geler les écritures : chaque clé d’accès et chaque clé de lien de charge de travail émise par Opfield sur le cluster MinIO passe en lecture seule, y compris les clés émises pendant le gel. Opfield cesse aussi d’y écrire : les téléversements, suppressions et modifications de buckets via l’explorateur d’objets, les outils de stockage et MCP échouent avec STORAGE_WRITES_FROZEN, et les sauvegardes ou restaurations qui y écriraient sont refusées. Le gel est refusé tant qu’une sauvegarde ou une restauration qui utilise le cluster est en cours. Les identifiants root et les tâches de copie continuent d’écrire ; la copie se poursuit donc. Les clés qu’Opfield n’a pas émises sont listées afin que vous puissiez arrêter ces clients. La page de détail du stockage indique que les écritures sont suspendues.
   • Passe finale : une tâche de copie sync s’exécute jusqu’à ce que son rapport soit propre. Rien ne bascule avant.
   • Importer les clés d’accès : les clés d’accès sont recréées sur SeaweedFS avec le même identifiant et le même secret ; leurs clients ne changent donc que le point de terminaison. Les clés qui expirent et les identifiants que SeaweedFS n’accepte pas sont listés pour remplacement.
   • Déplacer les liens de charges de travail : chaque lien passe sur le nouveau cluster avec la même clé, le même alias et les mêmes variables d’environnement. La charge de travail n’est pas recréée ; seule sa route privée change, et son connecteur est remplacé lorsque les clusters diffèrent quant à TLS. Chaque bucket du lien doit exister sur le nouveau cluster, sinon le déplacement est refusé avec MANAGED_STORAGE_BINDING_BUCKETS_MISSING. Un déplacement en échec est annulé et le lien reste sur MinIO ; s’il ne peut pas être rebasculé, le lien est laissé sur le nouveau cluster, marqué en échec, et signalé.
   • Recibler les Secure Links : les liaisons Secure Link des Routes basculent vers le nouveau cluster et conservent leur identifiant et leur nom ; les configurations de Routes qui les utilisent continuent donc de fonctionner. Si le nouveau cluster ne répond pas ou que la configuration de la Route ne peut pas être appliquée, l’ancienne cible est rétablie.
   • Vérifier les sauvegardes : une sauvegarde de chaque politique déplacée est exécutée, et les politiques suspendues sont réactivées après leur déplacement.
5. Vérifier et mettre hors service. Une fois que vous avez confirmé que les applications sont saines, l’assistant déplace l’historique des sauvegardes terminées vers SeaweedFS. Seules les exécutions dont tous les fichiers y sont trouvés avec leurs tailles enregistrées sont déplacées ; les autres restent sur MinIO et sont signalées, et doivent être recopiées ou oubliées avant que MinIO puisse être supprimé. L’assistant supprime ensuite le cluster MinIO, et un port S3 publié peut passer au nouveau cluster.

Tant que MinIO n’est pas supprimé, l’assistant peut revenir en arrière : geler le nouveau cluster, recopier vers MinIO avec sync les écritures effectuées après la bascule jusqu’à ce que le rapport soit propre, ramener les liens, les Secure Links et les politiques de sauvegarde, et dégeler MinIO. Les clés d’accès MinIO créées avant qu’Opfield n’attache une politique à chaque clé disposaient de l’accès complet de l’utilisateur root ; après un gel puis un dégel, elles ne conservent qu’un accès en lecture et en écriture à leurs buckets.

Pendant une migration, ne redémarrez, ne mettez à jour et ne relancez jamais le cluster MinIO, et ne modifiez pas sa publication : chacune de ces actions recrée son conteneur, et l’image peut ne plus être téléchargeable. Les droits storage:* limités à une ressource et le placement dans les dossiers ne sont pas copiés vers le nouveau cluster ; accordez-les à nouveau. Le versionnage des buckets, les règles de cycle de vie et les politiques de buckets ne sont pas non plus copiés.

Actions de migration

Pour migrer sans l’assistant, appelez les mêmes actions via l’API REST ou MCP dans l’ordre ci-dessus. Les actions sur le stockage managé prennent des identifiants de stockages managés ; les tâches de copie prennent des identifiants de connexions de stockage.

Étape	API REST	MCP et assistant	Permission
Copier les données	POST /api/storage/copy-jobs	manage_storage_connection copy_data_start	Voir Copier des données entre stockages
Geler les écritures	POST /api/managed-storage/{id}/freeze-writes	manage_managed_storage freeze_writes	storage:iam
Dégeler les écritures	POST /api/managed-storage/{id}/unfreeze-writes	unfreeze_writes	storage:iam ; autorisé aussi après la fin d’une période de grâce de licence
Importer les clés d’accès	POST /api/managed-storage/{targetId}/iam-keys/import avec sourceStorageId et éventuellement keyIds	import_access_keys	storage:iam sur les deux clusters
Déplacer un lien de charge de travail	POST /api/managed-storage/{id}/bindings/{bindingId}/move avec targetStorageId	move_binding	storage:iam sur les deux clusters et les permissions sur la charge de travail nécessaires pour créer un lien
Recibler un Secure Link	POST /api/proxy-hosts/{routeId}/additional-secure-links/{bindingId}/retarget avec upstreamKind: "managed_storage" et managedStorageId	manage_additional_secure_link retarget	proxy:edit sur la Route et storage:view sur le nouveau cluster
Déplacer l’historique des sauvegardes	POST /api/managed-storage/{id}/backup-history/rehome avec targetStorageId et éventuellement dryRun	rehome_backup_history	storage:edit sur les deux clusters

Le gel des écritures nécessite un démon à jour sur le nœud Storage du cluster MinIO ; la mise à jour du démon ne recrée pas le conteneur MinIO. Déplacez ou suspendez d’abord les politiques de sauvegarde qui écrivent dans le cluster : le gel est refusé tant qu’une sauvegarde ou une restauration qui utilise le cluster est en cours, et son résultat indique les politiques qui l’utilisent encore. Un gel partiel renvoie une erreur et laisse le cluster gelé ; relancez-le pour appliquer les clés restantes. Le déplacement de l’historique des sauvegardes est refusé tant que des exécutions de sauvegarde sont actives et ne modifie jamais les politiques. Les actions nécessitent un plan Personal ou supérieur en cours de validité, sauf le dégel, afin qu’un gel puisse toujours être levé. Chaque action est enregistrée dans le journal d’audit.

Supprimer un stockage auquel des sauvegardes font référence

Les politiques de sauvegarde et les exécutions de sauvegarde actives bloquent toujours la suppression d’une connexion de stockage ou d’un stockage managé ; supprimez ou déplacez les politiques et attendez la fin des exécutions. Lorsque seul un historique de sauvegardes terminées fait référence au stockage, la suppression est refusée avec STORAGE_BACKUP_HISTORY_EXISTS (409) jusqu’à ce que vous confirmiez Forget history and delete. L’oubli retire cet historique d’Opfield ; ces sauvegardes ne peuvent donc plus être restaurées ni supprimées depuis Opfield, et le journal d’audit enregistre l’emplacement de leurs fichiers. Les fichiers d’une connexion de stockage restent dans ses buckets ; les fichiers d’un stockage managé sont effacés avec lui.

Via l’API, passez backupHistory=forget à DELETE /api/object-storage/{id} ou DELETE /api/managed-storage/{id}. Les outils de stockage d’AI Workspace et de MCP acceptent la même confirmation sous la forme config.backupHistory. Pour supprimer d’abord des sauvegardes individuelles avec leurs fichiers, utilisez l’historique des sauvegardes.

Permissions

Scope	Autorise
storage:view	Consulter les connexions de stockage, le stockage managé, les clés d’accès et les liens
storage:create	Créer des connexions de stockage et du stockage managé
storage:edit	Modifier les paramètres, redémarrer et relancer le provisionnement
storage:delete	Supprimer des connexions de stockage et du stockage managé
storage:credentials:reveal	Afficher les identifiants enregistrés ; inclut storage:credentials:use
storage:credentials:use	Permettre aux sauvegardes de bases de données et aux tâches de copie d’utiliser les identifiants enregistrés sans les afficher
storage:iam	Créer, révoquer et importer des clés d’accès, geler et dégeler les écritures, et déplacer des liens de charges de travail ; inclut storage:bind
storage:bind	Créer et supprimer des liens de charges de travail sans émettre de clés d’accès
storage:objects:read	Parcourir et télécharger des objets et créer des liens de téléchargement présignés
storage:objects:write	Téléverser, créer des préfixes et supprimer des objets
storage:objects:admin	Créer et supprimer des buckets
storage:folders:manage	Organiser les dossiers de stockage

Les scopes peuvent être limités à une ressource de stockage ou à un dossier. Les sauvegardes de bases de données n’ont besoin que de storage:credentials:use sur leur destination, et non d’un accès aux objets. Voir la référence des scopes.

Limites d’exploitation

• Les ressources de stockage nécessitent Personal ou supérieur ; l’enrôlement d’un nœud Storage, non. Voir Plans et droits.
• Les nœuds Storage exécutent les bases de données managées, le stockage managé et les tâches de sauvegarde ; les conteneurs applicatifs génériques et les builds s’exécutent sur les nœuds Docker et les Build Workers. Voir Rôles des nœuds.
• Le stockage managé réside sur un seul hôte, sauf si Availability l’exécute sur plusieurs nœuds Storage. Conservez les sauvegardes et les autres copies importantes hors de son domaine de panne.
• Gardez le chiffrement côté destination, la conservation et les politiques d’accès dans le système de stockage qui détient les données.