MinIO Object Lock: retención, permisos y prueba
Guía para usar MinIO con retención WORM, versionado, lifecycle y prueba de restauración. Qué dato vive en la base y qué archivo queda protegido.
Perder un PDF firmado puede costar más que retenerlo 180 días con regla escrita. MinIO Object Lock protege versiones de objetos contra borrado antes del vencimiento y permite retención por duración o legal hold. Para una pyme con contratos, remitos o imágenes de inspección, esta guía muestra qué guardar en MinIO, qué queda en PostgreSQL y cómo probar la salida.
Dónde aparece el permiso de borrado heredado
El problema operativo aparece cuando el mismo usuario que sube una constancia también puede borrarla. La factura recurrente no está en el servidor; está en reconstruir archivos cuando compras, legales o calidad piden evidencia de una versión anterior. El antagonista es el permiso de borrado heredado, concedido por comodidad y olvidado después del primer mes. La cifra que corrige el hábito aparece en la documentación: el ejemplo de MinIO aplica un bloqueo WORM por 30 días sobre objetos de un bucket, y las reglas de lifecycle pueden expirar objetos por edad, por ejemplo después de 365 días. Retención y vencimiento conviven; una regla de expiración debe respetar cualquier bloqueo activo. La señal de uso sale de Stack Overflow 2025: las preocupaciones de seguridad o privacidad aparecen como la primera razón para rechazar una tecnología. En archivos de auditoría, esa objeción se baja a una pregunta visible: quién puede escribir, quién puede leer, quién puede borrar y cuándo. ## Cómo funciona por dentro MinIO guarda archivos grandes en buckets y conserva metadatos. PostgreSQL 18 guarda el índice operativo: cliente, expediente, estado, responsable, fecha, hash, versión y permiso. La aplicación sube el archivo a MinIO, recibe una clave de objeto y registra en PostgreSQL qué proceso lo creó. Object Lock protege versiones; versioning conserva cambios; lifecycle retira objetos cuando termina la política. 1. El usuario carga contrato, remito, foto o acta. 2. La aplicación valida formato, tamaño, responsable y expediente. 3. MinIO guarda el objeto con bucket, clave, metadatos y versión. 4. PostgreSQL guarda índice, estado, hash, usuario y auditoría. 5. El rol de revisión lee y aprueba; el rol de carga no borra. 6. Lifecycle vence objetos habilitados cuando termina la retención. 7. El backup copia base, configuración y buckets; una restauración abre un expediente real. La documentación de objetos y versioning muestra que la vida del archivo incluye versiones, reglas de ciclo y metadatos. Si PostgreSQL falla, la organización pierde el índice. Si MinIO falla, la base señala un archivo que no puede abrir. La prueba correcta restaura ambos. Un control útil deja tres evidencias: listado de objetos retenidos, registro de auditoría de la base y acta de restauración. El equipo no declara terminado el circuito hasta abrir un archivo desde un usuario de lectura, rechazar un borrado fuera de rol y recuperar el mismo hash desde una copia.
Qué se instala o configura primero
La pila inicial usa MinIO o AIStor, PostgreSQL 18, usuario de aplicación, grupos por rol, bucket con versionado, política de retención y tablero de archivos observados. El primer entregable verificable son veinte documentos simulados: cinco protegidos 30 días, cinco con vencimiento a 365 días, cinco observados y cinco listos para exportar. Cada registro abre archivo, hash, versión, responsable y fecha de retención. Para instalaciones con varios discos, erasure coding distribuye datos y paridad en conjuntos de discos. La herramienta de heal escanea objetos dañados o corruptos y puede repararlos, aunque es intensiva en recursos y debe planificarse. Esos dos puntos convierten el backup en una prueba, no en una promesa. Con dólar oficial vendedor a ARS 1.515, un servidor de pruebas de USD 45 mensuales más USD 12 de almacenamiento queda cerca de ARS 86.355 por mes. Un piloto de 22 a 34 horas técnicas a USD 30/h queda entre USD 660 y USD 1.020, es decir entre ARS 999.900 y ARS 1.545.300. Incluye buckets, permisos, retención, carga de prueba, tablero y restauración. Quedan fuera almacenamiento histórico completo y revisión legal de plazos. UMSA puede aplicar este patrón cuando la evidencia ya existe y el riesgo está en borrarla sin dejar rastro.
Dónde se rompe y cómo probarlo
El primer riesgo es activar Object Lock sin política escrita. La señal aparece cuando un archivo queda retenido más tiempo del necesario o menos de lo pactado. La prueba carga tres objetos, consulta fecha de retención y compara con la matriz aprobada. El segundo riesgo es lifecycle agresivo. Si expira una versión antes de vencer la retención, el resultado debe fallar y registrarse. La prueba crea versiones con fechas simuladas, ejecuta la regla y revisa cuáles quedaron. El tercer riesgo es índice separado de archivo. La señal aparece cuando el tablero dice aprobado y el objeto devuelve error. La prueba restaura PostgreSQL y MinIO en otra máquina, abre tres expedientes y compara hash, versión y metadatos. El archivo protegido sirve cuando alguien puede explicar su dueño, su vencimiento y su restauración.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.