Skip to main content
MinIO Community Edition entró en distribución de mantenimiento/solo código fuente a finales de 2025 y su repositorio comunitario upstream se archivó en 2026. Los servidores existentes pueden seguir en ejecución, pero los binarios comunitarios upstream y la entrega normal de parches ya no son un ciclo de vida de producción fiable. Este estado upstream no crea un compromiso de CaseBender de operar, parchear, redistribuir ni soportar MinIO. Consulte los avisos oficiales actuales de MinIO y su contrato de proveedor para los términos autoritativos del ciclo de vida de terceros.

​
Política de CaseBender

  • Las instalaciones nuevas de producción no pueden seleccionar un proveedor nativo minio.
  • Los paquetes e instaladores de producción no incrustan un servicio MinIO, una credencial raíz, un volumen ni un SDK nativo de MinIO.
  • CaseBender no crea un bucket MinIO nuevo en tiempo de ejecución.
  • Los valores históricos del enum de la base de datos y el historial de migraciones se conservan para que las actualizaciones no destruyan ni reinterpretan los registros existentes.
  • Un servicio MinIO heredado puede usarse solo como origen de lectura durante una ventana de migración aprobada.
  • No se promete una fecha de retirada ni soporte a largo plazo más allá de la implementación actual. Las fechas específicas del cliente pertenecen a un plan de cambio aprobado.
No configure un endpoint heredado como un backend S3 genérico nuevo de producción sin certificación en vivo del producto exacto según la matriz de la versión actual.

​
Ventana de migración

Defina una ventana acotada con:
  • propietario y aprobador;
  • última imagen/versión de origen soportada y revisión de vulnerabilidades;
  • tiempos de congelación de escrituras y de decisión de reversión;
  • plazo de retención del origen;
  • conjunto de recuperación de PostgreSQL más versión exacta de objeto probado;
  • cualificación en vivo del destino;
  • objetivos RPO/RTO y evidencia de ensayo medida; y
  • aprobación de retención legal/retención antes de cualquier eliminación del origen.

​
Preserve antes de cambiar nada

Conserve ambos:
  1. una instantánea/archivo a nivel de almacenamiento del diseño original miniodata para recuperación ante desastres; y
  2. una exportación a nivel de objeto a través de la API S3 que preserve claves, metadatos cuando se soporten, versiones de objeto, tamaños y SHA-256 calculado de forma independiente.
El diseño interno del sistema de archivos de MinIO no es un formato de importación válido para otro proveedor. Nunca copie archivos internos del volumen directamente al almacenamiento de objetos local o en la nube. Haga una copia de seguridad de PostgreSQL en el mismo punto de consistencia y conserve .env, las claves de cifrado, AUDIT_INTEGRITY_SECRET, los digests de imagen de la versión, la confianza TLS y las credenciales de origen en los sistemas de secretos/recuperación aprobados.

​
Migración copy-first

Use Migración de almacenamiento:
  1. inventarie las referencias de objeto de PostgreSQL y las versiones exactas de origen;
  2. copie sin eliminar ni sobrescribir el origen;
  3. verifique el tamaño del destino y el SHA-256 descargado;
  4. registre cada elemento en StorageMigrationLedger;
  5. detenga las escrituras y copie el delta final;
  6. cambie las lecturas solo después de la verificación;
  7. mantenga las lecturas heredadas/duales disponibles solo durante la ventana de compatibilidad documentada; y
  8. retenga el origen en solo lectura hasta que expire la aprobación de reversión.
No use sync, no elimine el origen, no rote las credenciales requeridas ni cambie las claves de objeto durante la copia inicial.

​
Reversión

La reversión requiere el origen original y el punto de recuperación de base de datos coincidente. Detenga las escrituras, copie de vuelta los cambios solo del destino de forma no destructiva, verifique SHA-256 y, a continuación, restaure la configuración de perfil anterior. Si no se puede demostrar la copia inversa, restaure el conjunto completo de consistencia PostgreSQL más objetos. Nunca apunte una aplicación más antigua a un esquema de base de datos que no soporta.

​
Validación y cierre

Ejecute la cualificación en vivo del destino, las pruebas de carga/escaneo/promoción/descarga/eliminación de la aplicación, scripts/storage/verify-backup-restore.ts y un ensayo de reversión. Conserve la evidencia saneada, el estado del ledger, los recuentos, los hashes, RPO/RTO, las aprobaciones y la autorización de eliminación del origen.