> ## Documentation Index
> Fetch the complete documentation index at: https://docs.casebender.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ciclo de vida y migración de MinIO

> Política de CaseBender para implementaciones heredadas de MinIO Community Edition

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](/es/deployment/storage-migration-runbook):

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.