Almacenamiento

El área Storage gestiona dos tipos de recursos. Una conexión de almacenamiento registra el acceso a un almacenamiento de objetos o de archivos que se ejecuta en otro lugar. El almacenamiento gestionado es almacenamiento de objetos compatible con S3 que Opfield aprovisiona y ejecuta en un nodo Storage; los clústeres nuevos usan SeaweedFS. Ambos requieren Personal o superior. Los recursos de almacenamiento sirven como destinos de las copias de seguridad de bases de datos, y el almacenamiento gestionado puede dar a las cargas de trabajo un acceso privado limitado a determinados buckets.

Pregunta	Conexión de almacenamiento	Almacenamiento gestionado
Quién ejecuta el servicio	El proveedor o tu equipo de almacenamiento	Opfield, como SeaweedFS en un nodo Storage con un disco acotado, o en varios en Business y Enterprise
Protocolos	S3 (AWS S3, Cloudflare R2, MinIO, otros servicios compatibles con S3), SFTP, FTP, FTPS	S3
Explorador de objetos	Sí	Sí
Destino de copias de seguridad	Sí	Sí
Claves de acceso y enlaces de cargas de trabajo	No	Sí
Exposición pública	No aplicable	Privado por defecto; un listener S3 público es opcional
Eliminar	Elimina solo la conexión guardada en Opfield	Elimina el servicio y borra sus datos

Conexiones de almacenamiento

Selecciona Add Storage y elige un proveedor:

Proveedor	Datos de conexión
AWS S3, Cloudflare R2, MinIO, Other (S3-compatible)	Región, ID de la clave de acceso y clave de acceso secreta; un endpoint para todos menos AWS; token de sesión opcional, bucket predeterminado y direccionamiento por ruta (activado por defecto para MinIO)
SFTP	Host, puerto (22 por defecto), nombre de usuario, contraseña o clave privada con frase de paso opcional, y la SSH host key fingerprint SHA-256 del servidor, que es obligatoria y se comprueba en cada conexión
FTP, FTPS	Host, puerto (21, o 990 para FTPS implícito), nombre de usuario y contraseña; FTPS admite TLS explícito o Implicit TLS y siempre verifica el certificado del servidor con el almacén de confianza del sistema o con un CA Certificate que proporciones

Para FTP, FTPS y SFTP, los directorios bajo la Base Path configurada aparecen como buckets. SMB no es compatible.

Para cambiar una conexión guardada, abre Storage Settings en su página. Test connection, al pie del diálogo, comprueba la conexión guardada e indica el tiempo de respuesta; Save Changes guarda el formulario.

Opfield guarda cifrados los secretos, las huellas de las claves de host y los certificados de CA y nunca devuelve los secretos al formulario: dejar en blanco un campo secreto conserva el valor guardado, pero cambiar el endpoint, el host, el nombre de usuario, el protocolo o los ajustes de confianza requiere volver a introducir el secreto. Revelar las credenciales guardadas requiere storage:credentials:reveal. storage:credentials:use permite que las copias de seguridad de bases de datos y los trabajos de copia usen las credenciales guardadas sin revelarlas. Un bucket al que hacen referencia políticas de copia de seguridad o el historial de copias no se puede eliminar; para las conexiones de almacenamiento, consulta Elimina un almacenamiento al que hacen referencia las copias de seguridad.

La pestaña Objects recorre los buckets y los objetos, abre y edita archivos, sube archivos, crea carpetas y elimina archivos y carpetas. No está disponible mientras el almacenamiento está sin conexión. Crear un bucket aparece cuando una conexión no tiene buckets y requiere storage:objects:admin. La API además elimina buckets y crea enlaces de descarga prefirmados; los enlaces prefirmados no están disponibles para el almacenamiento gestionado privado, que debe descargarse a través de Opfield, ni para FTP, FTPS y SFTP. Pedir un objeto o un bucket que no existe devuelve STORAGE_NOT_FOUND. Consulta Permisos.

Los clientes MCP mueven los objetos grandes sin base64 en las llamadas a herramientas: download_storage_object comprueba storage:objects:read y devuelve un enlace de un solo uso, válido durante 15 minutos, con un comando curl listo para usar que transmite el objeto a través de Opfield, y upload_storage_object sube por fragmentos que Opfield verifica. Un enlace de descarga se vuelve a comprobar contra los permisos actuales del propietario cuando se usa, y funciona una sola vez.

Almacenamiento de objetos gestionado

Elige Deploy managed storage para aprovisionar almacenamiento de objetos en un nodo Storage, opcionalmente en una carpeta de almacenamiento; el selector de carpetas solo ofrece las carpetas en las que puedes crear almacenamiento. Los clústeres nuevos ejecutan SeaweedFS 4.47, fijado a un digest de imagen inmutable; no hay cambio de versión en su sitio. El nodo Storage descarga el build propio de Opfield de SeaweedFS 4.47 desde GitHub Container Registry (ghcr.io); cuando no puede, usa la imagen original, primero desde el mirror de Opfield en ghcr.io y después desde Docker Hub, verificando su digest en ambos casos. Si no funciona ninguna fuente, el aprovisionamiento se detiene con MANAGED_STORAGE_IMAGE_PULL_FAILED.

Un clúster se ejecuta en un nodo Storage. En Business y Enterprise también puede ejecutarse en 2 a 5 nodos Storage con un primario y copias que toman el relevo cuando se pierde; consulta Bases de datos y almacenamiento en varios servidores. Fija los límites de CPU, memoria (al menos 512 MiB) y disco al aprovisionarlo; la consola limita el disco al espacio libre del nodo menos su reserva. El disco es una imagen acotada y preasignada en el nodo Storage, como el almacenamiento de las bases de datos gestionadas: cada clúster ocupa allí un dispositivo loop, y el daemon de Docker arranca el motor solo cuando esa imagen está montada; consulta Detalles para operadores: almacenamiento y TLS directo. Opfield genera las credenciales root, y revelarlas requiere storage:credentials:reveal.

Después del aprovisionamiento puedes cambiar el nombre, las etiquetas, la CPU, la memoria, el swap, el tamaño del disco y la publicación S3. El disco solo puede crecer, y un cambio se rechaza mientras todavía se está aplicando uno anterior. Ampliar el disco, y activar o desactivar la publicación o cambiar su puerto, recrean el contenedor del almacenamiento; los datos y las claves se conservan. También están disponibles Restart y el reintento de un aprovisionamiento fallido.

Los nombres de los almacenamientos gestionados son únicos en cada nodo Storage. Crear o renombrar un almacenamiento gestionado con un nombre que ya usa otro almacenamiento gestionado del mismo nodo falla con 409 MANAGED_STORAGE_NAME_IN_USE; si ese otro almacenamiento no llegó a aprovisionarse, reinténtalo o elimínalo antes. Un nombre queda libre en cuanto su almacenamiento empieza a eliminarse. Cuando Opfield se actualizó a la 2.11, los clústeres posteriores que compartían nombre en un nodo se renombraron con el primer sufijo libre -2, -3, …, junto con su conexión de almacenamiento; consulta Conflictos resueltos por la actualización a la 2.11.

El almacenamiento gestionado es privado por defecto. Opfield llega a él a través de rutas de Relay autenticadas. Puedes activar de forma explícita caminos de acceso adicionales:

• Publish S3 endpoint expone la API S3 en un puerto del host, 9000 por defecto.
• TLS cifra el endpoint S3 con un certificado de la Opfield Storage CA. Se elige al crear el clúster y no se puede activar después. Los clientes deben confiar en esa CA: el diálogo de credenciales muestra su huella SHA-256 y permite descargarla como storage-ca.pem o copiarla. A través de la API, GET /api/managed-storage/{id}/ca-certificate devuelve el certificado y la huella a cualquiera que pueda ver el clúster, o MANAGED_STORAGE_TLS_DISABLED (409) cuando TLS está desactivado; la herramienta MCP manage_managed_storage ofrece lo mismo como la acción ca_certificate.

Los clústeres SeaweedFS solo ofrecen S3; no tienen listeners FTP ni SFTP.

Las copias de seguridad de bases de datos y los trabajos de copia llegan al almacenamiento gestionado a través de un listener local y verifican su certificado como localhost o 127.0.0.1. Opfield añade esos nombres automáticamente a los certificados de los clústeres creados con una versión anterior. Mientras se aplica el nuevo certificado, las copias de seguridad esperan en la cola con el motivo indicado y se reintentan solas; solo fallan con BACKUP_STORAGE_CERTIFICATE_OUTDATED si el certificado no se sirve en 7 horas. Opfield no cambia los cortafuegos de los hosts. Abre solo los puertos que necesite un cliente identificado.

Renovación del certificado TLS

Opfield renueva automáticamente el certificado de un clúster con TLS, con una comprobación cada hora: cuando han transcurrido dos tercios de su tiempo de vida, quedan 30 días o menos, falta un nombre necesario o el certificado procede de otra CA. El daemon del nodo Storage escribe el nuevo certificado y el motor lo recarga sin reiniciarse; Opfield pasa a él solo cuando el clúster lo sirve. La Storage CA no cambia, así que los clientes siguen funcionando.

• Connection Details, en el almacenamiento, muestra una fila discreta TLS Certificate con la fecha de caducidad y “renewed automatically” o “needs attention”. Solo aparece un aviso en la página cuando se necesita atención (la renovación falló, quedan 7 días o menos, el certificado renovado todavía no está cargado, la renovación espera al daemon del nodo o la CA limita el tiempo de vida), con el motivo, la fecha de caducidad y Renew now para los usuarios que pueden editar el almacenamiento. El Dashboard también enumera cada almacenamiento gestionado y cada base de datos gestionada cuyo certificado necesita atención y que puedes ver. A través de la API y de MCP puedes renovarlo en cualquier momento.
• Solo se usa un reinicio cuando quedan 7 días o menos, cuando lo permites en una renovación manual o cuando renuevas manualmente en un nodo cuyo daemon todavía no puede recargar certificados. En caso contrario, ese nodo conserva el certificado actual hasta que se actualiza su daemon.
• Los clústeres SeaweedFS creados antes de la 2.11 solo vuelven a leer sus archivos de certificado cada pocas horas, así que una renovación puede tardar ese tiempo en servirse; permite un reinicio para aplicarla antes.
• Mientras la renovación sigue fallando, Opfield genera el evento de notificación Managed Service Certificate Renewal Failed, que desaparece tras una renovación correcta. Crea una regla de alerta para él. Las renovaciones se registran en el registro de auditoría.
• API: GET /api/managed-storage/{id}/certificate y POST /api/managed-storage/{id}/certificate/renew con allowRestart opcional; MCP y asistente: acciones certificate_status y renew_certificate de manage_managed_storage. Renovar requiere storage:edit y sigue funcionando cuando termina el periodo de gracia de una licencia.

Capacidad

Cada bucket se guarda en al menos un volumen de datos propio, y Opfield dimensiona los volúmenes a partir del disco, así que cuenta con aproximadamente un volumen de datos por bucket y prefiere un número moderado de buckets. Cuando el disco está lleno, las escrituras fallan con HTTP 500 mientras los objetos existentes siguen pudiéndose leer; libera espacio eliminando objetos, o amplía el disco en los ajustes, lo que recrea el contenedor, y las escrituras se reanudan.

Claves de acceso y enlaces de cargas de trabajo

En la página de detalle del almacenamiento, la pestaña IAM Keys emite credenciales S3 con un nombre opcional, acceso de solo lectura o de lectura y escritura, hasta 64 buckets (ninguno significa todos los buckets) y una caducidad opcional. Cada clave es su propio principal IAM en el motor, limitado a sus buckets: puede enumerar solo esos buckets, leer objetos y, con acceso de lectura y escritura, escribir y eliminar objetos, pero no puede crear ni eliminar buckets. El propio motor aplica la caducidad, y revocar una clave elimina su principal de inmediato. La clave secreta se muestra una vez al crear la clave. Crear y revocar claves requiere storage:iam.

El diálogo de credenciales muestra comandos de inicio rápido de AWS CLI y rclone. Para un clúster con TLS, pasan la CA descargada como --ca-bundle storage-ca.pem (AWS CLI) o --ca-cert storage-ca.pem (rclone). Con una clave limitada a determinados buckets, rclone necesita no_check_bucket = true (incluido en el inicio rápido); si no, intenta crear el bucket y falla con 403.

Un enlace de almacenamiento gestionado da a un Container o a un Deployment acceso privado a entre 1 y 32 buckets. Añádelo desde la pestaña Environment de la carga de trabajo; los servicios de Compose no son compatibles. Opfield emite una clave limitada a esos buckets, conecta la carga de trabajo a una pequeña red privada propia para el enlace, servida por el conector de Secure Links compartido de su nodo Docker, y guarda los valores como secretos gestionados en variables de entorno cuyos nombres predeterminados son S3_ENDPOINT, AWS_ACCESS_KEY_ID, AWS_SECRET_ACCESS_KEY, S3_BUCKET (el primer bucket) y AWS_REGION. La clave solo puede llegar a los buckets indicados, así que una carga de trabajo comprometida no puede leer el resto del almacenamiento. Los buckets que indica el enlace y que todavía no existen se crean al crear el enlace, porque la propia clave del enlace no puede crearlos. Crear un enlace requiere storage:bind (incluido en storage:iam) y permiso para editar el entorno y los secretos de la carga de trabajo; un enlace en un Deployment también requiere docker:containers:manage sobre él, más docker:containers:edit cuando cambia el entorno del Deployment.

Un enlace no tiene un límite fijo de conexiones: la admisión de Relay lo acota según la carga y reparte la capacidad de forma equitativa entre las rutas, y las conexiones inactivas de los pools permanecen abiertas. La vista general de la carga de trabajo muestra el estado de ejecución del enlace junto a sus enlaces de bases de datos. Consulta Capacidad de los enlaces y pools de conexiones.

Desde la 2.11.1, los enlaces de almacenamiento funcionan con el conector compartido, igual que las vinculaciones de bases de datos y los container links, sin un contenedor conector por enlace. Un enlace creado antes de la 2.11.1 pasa a él cuando se actualiza el daemon de Docker de la carga de trabajo, y Opfield recrea una vez la carga de trabajo enlazada justo después del cambio: un Deployment se despliega en blue/green sin tiempo de inactividad, y un Container se reinicia una vez. Los enlaces creados en la 2.11.1 no necesitan recreación. Revertir el daemon de Docker a la 2.11.0 devuelve los enlaces por sí solo, de nuevo con una recreación por carga de trabajo.

No hace falta que la carga de trabajo esté en ejecución: un enlace puede apuntar a un Container o a un Deployment detenidos, en un bucle de fallos, fallidos o que todavía no se han desplegado, y Opfield lo guarda sin esperar a la carga de trabajo. Hasta que la carga de trabajo se ejecuta con el enlace, el enlace aparece como pending (observedState: "target_applied" en la API y en MCP); pasa a estar activo cuando la carga de trabajo vuelve a arrancar o termina su despliegue actual, y reintentar un build de Git fallido lo despliega. A través de la API, de MCP o del asistente, también se puede enlazar por su nombre un Container con origen Git antes de su primer build, que entonces lo arranca con el enlace. Una reversión o un cambio de slot de un Deployment conservan los enlaces actuales. El nodo Docker de la carga de trabajo debe estar en línea.

Para configuraciones avanzadas de nginx, una Route también puede usar una vinculación de Secure Link adicional hacia un almacenamiento de objetos gestionado listo, sin una red Docker compartida ni un puerto S3 publicado; los clientes siguen necesitando credenciales S3. El almacenamiento gestionado no puede ser el upstream principal de una Route. Crear la vinculación requiere acceso de edición a la Route y acceso de visualización al almacenamiento; consulta Upstreams seguros.

Eliminar un almacenamiento gestionado borra sus datos y elimina automáticamente sus enlaces de cargas de trabajo. Se rechaza mientras le hagan referencia vinculaciones de Secure Link de Routes o un trabajo de copia activo, y las referencias de las copias de seguridad se tratan como se describe más abajo.

Las redes de almacenamiento gestionadas por Opfield (opfield-storage-*; gateway-storage-* para las redes creadas antes de la 2.12.1) están ocultas a las acciones de redes de Docker: los usuarios no pueden conectar ni desconectar contenedores, eliminar estas redes ni crear contenedores en ellas.

Copia datos entre almacenamientos

Un trabajo de copia copia objetos del lado del servidor de un almacenamiento S3 a otro, gestionado o externo; por ejemplo, de un clúster MinIO heredado a SeaweedFS, o de un bucket externo a un almacenamiento gestionado. Los trabajos de copia no tienen pantalla en la consola: inícialos desde el asistente integrado, MCP o la REST API.

• Modos: copy añade y sobrescribe objetos y nunca elimina. sync también elimina los objetos de destino que el origen no tiene; úsalo solo para una pasada final deliberada. dryRun no escribe nada e informa de lo que difiere.
• Destinos en uso: un sync hacia un almacenamiento gestionado que todavía usan enlaces de cargas de trabajo o claves de acceso con escritura, y cuyas escrituras no están congeladas, se rechaza con STORAGE_COPY_DESTINATION_LIVE, porque podría eliminar objetos que escribieron esos clientes. Congela las escrituras del destino, usa copy o pasa allowLiveDestination: true cuando aceptes ese riesgo.
• Buckets: "all" o una lista de nombres. Cada bucket conserva su nombre en el destino. Los buckets de destino que faltan se crean cuando tienes storage:objects:admin sobre el destino; pasa createBuckets: false para exigir buckets existentes. No se copian el versionado de los buckets, las reglas de ciclo de vida ni las políticas de los buckets.
• Ejecución: el runner de copias de seguridad de un nodo Storage transmite los objetos con rclone, conservando los metadatos de los objetos como el tipo de contenido, y después compara ambos lados. Opfield elige un nodo Storage en línea cuyo daemon admita trabajos de copia, o lo eliges tú con executorNodeId. Al almacenamiento gestionado privado se llega a través de rutas de Relay por trabajo, así que no se publica ningún puerto ni se recrea ningún contenedor. Las credenciales se quedan dentro de Opfield y del ejecutor. limits opcionales: timeoutSeconds (un día por defecto, como máximo siete), cpuCores, memoryMb y transfers.
• Informe de comprobación: un trabajo terminado informa, por bucket y en total, del número de objetos y de bytes en ambos lados, del número de objetos que faltan, que difieren y (para sync) que sobran, con claves de ejemplo, y de clean. Solo un trabajo completado con clean: true demuestra la copia; un trabajo completado todavía puede informar de diferencias, por ejemplo de objetos escritos por clientes mientras se ejecutaba. Volver a ejecutar el mismo trabajo solo transfiere lo que ha cambiado, e intercambiar el origen y el destino copia en sentido contrario.
• Límites: solo un trabajo activo puede escribir en un almacenamiento, ningún trabajo puede leer un almacenamiento en el que esté escribiendo otro trabajo, y un ejecutor ejecuta como máximo dos trabajos de copia a la vez.

Acción	REST API	MCP y asistente
Iniciar un trabajo	POST /api/storage/copy-jobs con sourceStorageId, destinationStorageId, buckets, mode, dryRun y, opcionalmente, createBuckets, allowLiveDestination, executorNodeId y limits	manage_storage_connection copy_data_start
Seguir un trabajo y leer su informe	GET /api/storage/copy-jobs/{id}	copy_data_status
Listar los trabajos	GET /api/storage/copy-jobs	copy_data_list
Cancelar un trabajo	POST /api/storage/copy-jobs/{id}/cancel	copy_data_cancel

Los trabajos de copia usan ID de conexiones de almacenamiento. Para un almacenamiento gestionado, usa el ID de su conexión de almacenamiento (objectStorageConnectionId en los detalles del almacenamiento gestionado que devuelven la API y MCP), no el ID del almacenamiento gestionado.

Un trabajo cancelado o que agota su tiempo nunca deja un contenedor runner, y su estado final se guarda antes de informar de él, así que sobrevive a un reinicio del daemon justo después.

Iniciar un trabajo requiere storage:objects:read y storage:credentials:use sobre el origen, storage:objects:write y storage:credentials:use sobre el destino, y nodes:backups:execute sobre el nodo ejecutor. Opfield vuelve a comprobar los permisos del propietario del trabajo cuando lo envía. Iniciar un trabajo requiere un plan Personal o superior vigente; seguir, listar y cancelar trabajos sigue funcionando cuando termina el periodo de gracia de una licencia.

Migración desde MinIO

Su fabricante ya no distribuye MinIO, así que el almacenamiento gestionado nuevo ejecuta SeaweedFS. Los clústeres MinIO gestionados creados con versiones anteriores siguen funcionando como motor heredado y aparecen marcados como Legacy MinIO engine en la consola:

• Siguen sirviendo S3, sus claves de acceso, sus enlaces de cargas de trabajo, sus vinculaciones de Secure Link y cualquier listener FTP o SFTP, y las operaciones diarias continúan mientras la imagen de MinIO siga en el nodo Storage.
• No se pueden crear clústeres MinIO nuevos.
• Una operación que necesite recrear el contenedor y, por tanto, descargar la imagen (por ejemplo, cambiar la publicación, ampliar el disco o recuperar un contenedor perdido) falla con MANAGED_STORAGE_ENGINE_IMAGE_UNAVAILABLE si la imagen ya no está en el nodo, porque ya no se puede descargar. Opfield lo indica antes de tocar el contenedor o sus datos.

Migra con el asistente

No hay un botón de migración. Para trasladar un clúster a SeaweedFS, pídeselo al asistente integrado, por ejemplo: Migra el almacenamiento gestionado «files» de MinIO a SeaweedFS. El asistente sigue paso a paso la guía de migración de Opfield, informa del resultado de cada paso y pregunta antes del cambio final y antes de retirar el clúster MinIO. Actúa con tus permisos, así que necesitas los ámbitos indicados en Acciones de migración. Un cliente MCP como Codex o Claude Code puede ejecutar la misma migración con las mismas herramientas.

1. Comprobación previa (solo lectura). El asistente comprueba que el clúster está listo, enumera sus buckets, el espacio usado, las claves de acceso, los enlaces de cargas de trabajo, los Secure Links y las políticas y el historial de copias de seguridad, y comprueba que el nodo de destino tiene libre al menos 1,2 veces el espacio usado y un daemon actualizado. Se detiene si el clúster usa FTP o SFTP, que SeaweedFS no ofrece.
2. Construye el destino. Crea un clúster SeaweedFS, privado por defecto. Si se le pide, reutiliza las credenciales root de MinIO para que los clientes que las usan sigan funcionando.
3. Copia en línea. Un trabajo de copia copia todos los buckets mientras las aplicaciones siguen escribiendo en MinIO. El informe puede mostrar diferencias mientras los clientes escriben, así que la copia se repite hasta que solo difieren objetos recientes; cada ejecución transfiere solo lo que ha cambiado.
4. Cambio final. Las escrituras se pausan durante una ventana breve; las lecturas siguen funcionando.
   • Mueve primero las copias de seguridad: las políticas de copia de seguridad que escriben en el clúster MinIO se mueven al nuevo clúster, o se pausan si lo prefieres, y los trabajos de copia de seguridad y restauración en curso que lo usan deben terminar o cancelarse.
   • Congela las escrituras: todas las claves de acceso y las claves de enlaces de cargas de trabajo que Opfield emitió en el clúster MinIO pasan a ser de solo lectura, incluidas las claves emitidas durante la congelación. Opfield también deja de escribir allí: las subidas, las eliminaciones y los cambios de buckets a través del explorador de objetos, las herramientas de almacenamiento y MCP fallan con STORAGE_WRITES_FROZEN, y se rechazan las copias de seguridad o las restauraciones que escribirían allí. La congelación se rechaza mientras se esté ejecutando una copia de seguridad o una restauración que use el clúster. Las credenciales root y los trabajos de copia siguen escribiendo, así que la copia continúa. Las claves que Opfield no emitió se enumeran para que puedas detener esos clientes. La página de detalle del almacenamiento muestra que las escrituras están pausadas.
   • Pasada final: se ejecuta un trabajo de copia sync hasta que su informe está limpio. No se cambia nada antes de que lo esté.
   • Importa las claves de acceso: las claves de acceso se vuelven a crear en SeaweedFS con el mismo ID y el mismo secreto, de modo que sus clientes solo cambian el endpoint. Las claves con caducidad y los ID que SeaweedFS no acepta se enumeran para sustituirlos.
   • Mueve los enlaces de cargas de trabajo: cada enlace pasa al nuevo clúster con la misma clave, el mismo alias y las mismas variables de entorno. La carga de trabajo no se recrea; solo cambia su ruta privada, y su conector se sustituye cuando los clústeres difieren en TLS. Todos los buckets del enlace deben existir en el nuevo clúster; si no, el traslado se rechaza con MANAGED_STORAGE_BINDING_BUCKETS_MISSING. Un traslado fallido se revierte y el enlace se queda en MinIO; si no se puede volver atrás, el enlace se deja en el nuevo clúster, marcado como fallido, y se informa de ello.
   • Redirige los Secure Links: las vinculaciones de Secure Link de las Routes pasan al nuevo clúster y conservan su ID y su nombre, de modo que las configuraciones de Route que las usan siguen funcionando. Si el nuevo clúster no responde o no se puede aplicar la configuración de la Route, se restaura el destino anterior.
   • Comprueba las copias de seguridad: se ejecuta una copia de seguridad de cada política trasladada, y las políticas pausadas se vuelven a activar después de trasladarlas.
5. Verifica y retira. Cuando confirmas que las aplicaciones están en buen estado, el asistente traslada el historial de copias de seguridad terminadas a SeaweedFS. Solo se trasladan las ejecuciones cuyos archivos se encuentran todos allí con sus tamaños registrados; las demás se quedan en MinIO y se notifican, y deben volver a copiarse u olvidarse antes de poder eliminar MinIO. Después, el asistente elimina el clúster MinIO, y un puerto S3 publicado puede pasar al nuevo clúster.

Hasta que se elimine MinIO, el asistente puede revertir: congela el nuevo clúster, copia de vuelta a MinIO con sync las escrituras hechas después del cambio final hasta que el informe esté limpio, devuelve los enlaces, los Secure Links y las políticas de copia de seguridad y descongela MinIO. Las claves de acceso de MinIO creadas antes de que Opfield asociara una política a cada clave tenían el acceso completo del usuario root; tras una congelación y una descongelación, solo conservan el acceso de lectura y escritura a sus buckets.

Durante una migración, no reinicies, actualices ni reintentes nunca el clúster MinIO ni cambies su publicación: cada una de esas acciones recrea su contenedor, y puede que la imagen ya no se pueda descargar. Las concesiones storage:* limitadas por recurso y la ubicación en carpetas no se copian al nuevo clúster; vuelve a concederlas. Tampoco se copian el versionado de los buckets, las reglas de ciclo de vida ni las políticas de los buckets.

Acciones de migración

Para migrar sin el asistente, llama a las mismas acciones a través de la REST API o de MCP en el orden anterior. Las acciones de almacenamiento gestionado usan ID de almacenamiento gestionado; los trabajos de copia usan ID de conexiones de almacenamiento.

Paso	REST API	MCP y asistente	Permiso
Copiar datos	POST /api/storage/copy-jobs	manage_storage_connection copy_data_start	Consulta Copia datos entre almacenamientos
Congelar las escrituras	POST /api/managed-storage/{id}/freeze-writes	manage_managed_storage freeze_writes	storage:iam
Descongelar las escrituras	POST /api/managed-storage/{id}/unfreeze-writes	unfreeze_writes	storage:iam; también permitido cuando termina el periodo de gracia de una licencia
Importar las claves de acceso	POST /api/managed-storage/{targetId}/iam-keys/import con sourceStorageId y keyIds opcional	import_access_keys	storage:iam sobre ambos clústeres
Mover un enlace de carga de trabajo	POST /api/managed-storage/{id}/bindings/{bindingId}/move con targetStorageId	move_binding	storage:iam sobre ambos clústeres y los permisos sobre la carga de trabajo necesarios para crear un enlace
Redirigir un Secure Link	POST /api/proxy-hosts/{routeId}/additional-secure-links/{bindingId}/retarget con upstreamKind: "managed_storage" y managedStorageId	manage_additional_secure_link retarget	proxy:edit sobre la Route y storage:view sobre el nuevo clúster
Mover el historial de copias de seguridad	POST /api/managed-storage/{id}/backup-history/rehome con targetStorageId y dryRun opcional	rehome_backup_history	storage:edit sobre ambos clústeres

Congelar las escrituras requiere un daemon actualizado en el nodo Storage del clúster MinIO; actualizar el daemon no recrea el contenedor de MinIO. Mueve o pausa antes las políticas de copia de seguridad que escriben en el clúster: la congelación se rechaza mientras se esté ejecutando una copia de seguridad o una restauración que use el clúster, y su resultado indica las políticas que todavía lo usan. Una congelación parcial devuelve un error y deja el clúster congelado; vuelve a ejecutarla para aplicar las claves restantes. Mover el historial de copias de seguridad se rechaza mientras haya ejecuciones de copias activas y nunca cambia las políticas. Las acciones requieren un plan Personal o superior vigente, salvo la descongelación, para que siempre se pueda levantar una congelación. Cada acción queda registrada en el registro de auditoría.

Elimina un almacenamiento al que hacen referencia las copias de seguridad

Las políticas de copia de seguridad y las ejecuciones de copias activas siempre bloquean la eliminación de una conexión de almacenamiento o de un almacenamiento gestionado; elimina o mueve las políticas y espera a que terminen las ejecuciones. Cuando solo hace referencia al almacenamiento el historial de copias terminadas, la eliminación se rechaza con STORAGE_BACKUP_HISTORY_EXISTS (409) hasta que confirmas Forget history and delete. Olvidar elimina ese historial de Opfield, de modo que esas copias ya no se pueden restaurar ni eliminar desde Opfield, y el registro de auditoría anota dónde están sus archivos. Los archivos de una conexión de almacenamiento se quedan en sus buckets; los archivos de un almacenamiento gestionado se borran con él.

A través de la API, pasa backupHistory=forget a DELETE /api/object-storage/{id} o DELETE /api/managed-storage/{id}. Las herramientas de almacenamiento de AI Workspace y de MCP aceptan la misma confirmación como config.backupHistory. Para eliminar antes copias concretas junto con sus archivos, usa el historial de copias de seguridad.

Permisos

Ámbito	Permite
storage:view	Ver las conexiones de almacenamiento, el almacenamiento gestionado, las claves de acceso y los enlaces
storage:create	Crear conexiones de almacenamiento y almacenamiento gestionado
storage:edit	Cambiar los ajustes, reiniciar y reintentar el aprovisionamiento
storage:delete	Eliminar conexiones de almacenamiento y almacenamiento gestionado
storage:credentials:reveal	Revelar las credenciales guardadas; incluye storage:credentials:use
storage:credentials:use	Permitir que las copias de seguridad de bases de datos y los trabajos de copia usen las credenciales guardadas sin revelarlas
storage:iam	Crear, revocar e importar claves de acceso, congelar y descongelar las escrituras y mover enlaces de cargas de trabajo; incluye storage:bind
storage:bind	Crear y eliminar enlaces de cargas de trabajo sin emitir claves de acceso
storage:objects:read	Explorar y descargar objetos y crear enlaces de descarga prefirmados
storage:objects:write	Subir, crear prefijos y eliminar objetos
storage:objects:admin	Crear y eliminar buckets
storage:folders:manage	Organizar las carpetas de almacenamiento

Los ámbitos se pueden limitar a un recurso de almacenamiento o a una carpeta. Las copias de seguridad de bases de datos solo necesitan storage:credentials:use sobre su destino, no acceso a los objetos. Consulta la referencia de ámbitos.

Límites operativos

• Los recursos de almacenamiento requieren Personal o superior; registrar un nodo Storage no. Consulta Planes y derechos.
• Los nodos Storage ejecutan las bases de datos gestionadas, el almacenamiento gestionado y los trabajos de copia de seguridad; los contenedores de aplicaciones genéricos y los builds se ejecutan en los nodos Docker y en los Build Workers. Consulta Roles de los nodos.
• El almacenamiento gestionado está en un solo host salvo que Availability lo ejecute en varios nodos Storage. Mantén las copias de seguridad y otras copias importantes fuera de su dominio de fallo.
• Mantén el cifrado, la retención y las políticas de acceso del lado del destino en el sistema de almacenamiento que guarda los datos.