¿Dónde debe almacenar sus archivos una aplicación autoalojada? Un marco de decisión para volúmenes persistentes y almacenamiento de objetos

El almacenamiento de archivos es una decisión arquitectónica

Una aplicación autoalojada suele almacenar su estado duradero en más de un lugar. La base de datos puede contener registros, permisos y metadatos, mientras que archivos como cargas, documentos, imágenes e informes generados residen en disco o en un almacenamiento de objetos. Por tanto, restaurar solo la base de datos puede producir registros que apuntan a archivos que ya no existen.

En implementaciones con Docker, los datos escritos únicamente en la capa de escritura de un contenedor desaparecen cuando ese contenedor se destruye. Los archivos duraderos de la aplicación deben ubicarse en una ubicación explícitamente persistente que la aplicación admita. La opción correcta no es automáticamente el almacenamiento de objetos: es el patrón de almacenamiento que se ajusta al modelo de acceso a archivos de la aplicación, los requisitos de recuperación y la capacidad operativa del equipo. Consulte la documentación oficial de [volúmenes de Docker](https://docs.docker.com/engine/storage/volumes/).

• Trate cada ubicación de archivos como parte del modelo de datos de la aplicación.
• Diseñe las copias de seguridad y las restauraciones en torno a la base de datos y los archivos a los que hace referencia.
• Documente la ubicación de almacenamiento prevista en lugar de depender de una imagen de contenedor o de una ruta de host no documentada.

Comience con un inventario de archivos

Antes de elegir el almacenamiento, identifique cada categoría de datos que la aplicación crea o consume. Lea la documentación oficial de implementación y copias de seguridad de la aplicación, inspeccione las rutas y configuraciones establecidas, y realice una carga o exportación de prueba en un entorno que no sea de producción. El objetivo es conocer qué es autoritativo, qué se puede regenerar y qué se debe conservar.

No suponga que un directorio llamado uploads contiene toda la respuesta. Una aplicación puede guardar archivos originales, miniaturas, adjuntos privados, recursos de plugins, índices de búsqueda, cargas útiles de trabajos en cola o archivos de exportación en ubicaciones diferentes.

• Cargas y adjuntos de usuarios: originales proporcionados por usuarios o personal.
• Medios y derivados generados: imágenes, vistas previas, miniaturas o documentos transformados.
• Exportaciones generadas: informes, archivos CSV, facturas o descargas de archivos.
• Recursos gestionados por la aplicación: archivos creados mediante una interfaz administrativa.
• Cachés, sesiones y archivos de trabajo temporales: a menudo prescindibles, pero confírmelo en la documentación del proveedor.
• Registros y archivos de diagnóstico: útiles operativamente, pero normalmente se gestionan por separado de la recuperación de la aplicación.

Comprenda los tres patrones comunes de almacenamiento

Los volúmenes persistentes locales almacenan archivos fuera del ciclo de vida de un contenedor individual. Los volúmenes de Docker son gestionados por Docker y permanecen cuando se elimina el contenedor que los utiliza. En Kubernetes, los [PersistentVolumes](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) tienen igualmente un ciclo de vida independiente de un Pod individual. Este patrón suele ser adecuado para una única instancia de aplicación cuyo software espera acceso ordinario al sistema de archivos.

El almacenamiento de objetos guarda los datos como objetos en buckets, identificados mediante claves de objeto. Solo es adecuado cuando la aplicación admite explícitamente un servicio de almacenamiento de objetos o proporciona una integración compatible. Por ejemplo, [Rails Active Storage](https://guides.rubyonrails.org/active_storage_overview.html) admite tanto un servicio de disco local como servicios de almacenamiento en la nube, lo que ilustra que la elección de almacenamiento suele ser una decisión de configuración de la aplicación y no un cambio transparente de infraestructura.

Un sistema de archivos gestionado externamente puede ofrecer acceso compartido al sistema de archivos a las cargas de trabajo. Puede ser apropiado cuando la aplicación realmente lo requiere y la implementación de almacenamiento seleccionada admite el patrón de acceso necesario. Añade otro sistema que operar, proteger, respaldar y probar.

• Volumen persistente: semántica sencilla de sistema de archivos para un diseño compatible de un único host o nodo.
• Almacenamiento de objetos: acceso a objetos adaptado a la aplicación, potencialmente separado del host de computación.
• Sistema de archivos gestionado: semántica de sistema de archivos compartido cuando esté justificada por los requisitos de la aplicación.

Utilice una matriz de decisión en lugar de un valor predeterminado

Elija el almacenamiento por categoría de archivo, no necesariamente una sola vez para toda la aplicación. Una carga de trabajo de gestión documental puede necesitar almacenamiento duradero para adjuntos, mientras que su directorio temporal de conversión debería permanecer no persistente. Una aplicación de informes puede conservar los documentos fuente, pero regenerar las exportaciones después de una restauración.

Un diseño de almacenamiento es defendible cuando ofrece respuestas claras sobre durabilidad, compatibilidad de la aplicación, recuperación, portabilidad, control de acceso y mantenimiento rutinario.

• Durabilidad: ¿Qué ocurre si se reemplaza el contenedor, el host o el nodo?
• Compatibilidad: ¿La aplicación admite oficialmente este backend de almacenamiento y su configuración?
• Complejidad de restauración: ¿Puede el equipo restaurar los archivos y los datos de la base de datos a un punto conocido y compatible?
• Portabilidad de migración: ¿Se pueden exportar, copiar y validar los datos sin suposiciones no documentadas?
• Límites de acceso: ¿Qué identidad de servicio puede leer, escribir o eliminar los archivos?
• Sobrecarga operativa: ¿Quién se responsabiliza de las credenciales, la supervisión de capacidad, las reglas de retención y las pruebas de restauración?
• Modelo de escalado: ¿Más de un proceso de aplicación necesitará escribir los mismos archivos, y está eso admitido?

Restaure las bases de datos y los archivos como un sistema relacionado

La pregunta clave es si la base de datos contiene referencias a archivos o si los archivos son necesarios para interpretar los registros de la base de datos. Si un registro de adjunto hace referencia a una ruta o a una clave de objeto, el almacén de adjuntos y la base de datos necesitan una planificación de recuperación conjunta. Una restauración que combina una base de datos más reciente con archivos más antiguos, o a la inversa, puede dejar adjuntos ausentes o archivos sin referencias.

El orden exacto de restauración seguro depende de la aplicación. Algunos productos ofrecen un modo de mantenimiento, un comando de copia de seguridad o un procedimiento de restauración documentados; utilícelos cuando estén disponibles. Cuando la aplicación no disponga de un mecanismo de consistencia documentado, defina una breve ventana de mantenimiento u otro método controlado para reducir las escrituras mientras se realizan las copias de seguridad de la base de datos y los archivos.

• Identifique el sistema de registro para cada categoría de archivo.
• Registre si la base de datos almacena rutas, claves de objeto, sumas de verificación o metadatos de adjuntos.
• Defina un punto de recuperación aceptable tanto para la base de datos como para los archivos.
• Pruebe lo que los usuarios deben ver después de la restauración: cargas recientes, adjuntos antiguos, permisos y descargas.

Cuándo los volúmenes persistentes locales son la respuesta correcta

Un volumen persistente local suele ser la opción más clara para una implementación pequeña cuando la aplicación está diseñada para almacenamiento en el sistema de archivos local, se ejecuta como una instancia activa y el equipo puede hacer copias de seguridad y restaurar el volumen subyacente. Evita añadir una integración de almacenamiento de objetos únicamente porque parece más escalable.

La simplicidad es real solo si los detalles operativos son explícitos. Un volumen de Docker es gestionado por el host y un nombre de volumen local es único para ese host. Trasladar la aplicación a otro host requiere un proceso deliberado de transferencia y verificación de datos. Docker documenta un método para [archivar el contenido de un volumen y restaurarlo](https://docs.docker.com/engine/storage/volumes/) mediante un contenedor temporal, lo que puede respaldar un flujo de trabajo controlado de migración o recuperación.

• Monte el volumen duradero en la ruta de datos documentada de la aplicación.
• No confunda una ruta del sistema de archivos del contenedor con almacenamiento persistente.
• Registre el nombre del volumen, el destino de montaje, las expectativas de propiedad y el método de copia de seguridad.
• Compruebe el comportamiento de los montajes durante la implementación: montar un volumen no vacío oculta los archivos preexistentes de la imagen en ese destino; un volumen vacío puede rellenarse desde el directorio de la imagen, salvo que se desactive la copia. Consulte la documentación de [volúmenes de Docker](https://docs.docker.com/engine/storage/volumes/).
• Mantenga los datos temporales separados cuando sea posible; un montaje [tmpfs](https://docs.docker.com/engine/storage/) solo es adecuado para datos destinados a desaparecer al detenerse o reiniciarse el contenedor, o al reiniciarse el host.

Cuándo es adecuado el almacenamiento de objetos

El almacenamiento de objetos es una opción sólida cuando una aplicación lo admite de forma nativa y la carga de trabajo se beneficia de separar los objetos de archivo del host de la aplicación. No deduzca la compatibilidad del hecho de que una aplicación se ejecute en Docker. Confirme el backend admitido, las credenciales necesarias, la disposición del bucket, el comportamiento de asignación de nombres de objetos, la configuración de entrega de URL y cualquier procedimiento de migración en la documentación de la propia aplicación.

El almacenamiento de objetos cambia el modelo operativo en lugar de eliminarlo. Aún debe decidir quién puede acceder al bucket, cómo se gestiona la eliminación accidental, cómo afectan las versiones retenidas a la recuperación y si las reglas de ciclo de vida se ajustan a las obligaciones de retención de la organización. En Amazon S3, por ejemplo, los buckets con y sin versionado presentan [comportamientos de eliminación diferentes](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DeletingObjects.html), y las [reglas de ciclo de vida](https://docs.aws.amazon.com/AmazonS3/latest/userguide/object-lifecycle-mgmt.html) pueden realizar transiciones, archivar o eliminar objetos.

• Utilice un bucket dedicado o un prefijo claramente aislado cuando el diseño de la aplicación lo admita.
• Conceda a la aplicación solo los permisos que necesita; mantenga las credenciales de servicio separadas de la administración humana. Consulte las recomendaciones de [control de acceso de Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/access-management.html).
• Documente cómo se conservan o eliminan los originales, los derivados y las cargas abandonadas.
• Pruebe la recuperación utilizando la misma configuración de bucket y el mismo modelo de acceso previstos para producción.
• Asegúrese de que una política de ciclo de vida no pueda eliminar datos que la aplicación o sus usuarios aún necesitan.

No convierta un sistema de archivos de red compartido en la opción predeterminada

Un sistema de archivos de red compartido puede parecer una respuesta sencilla cuando intervienen varios contenedores o nodos, pero debe responder a un requisito de la aplicación, no precederlo. Varios escritores introducen cuestiones de bloqueo, cambios concurrentes, permisos y comportamiento ante fallos que las aplicaciones pueden no estar diseñadas para gestionar.

Los modos de acceso al almacenamiento de Kubernetes tampoco sustituyen la coordinación a nivel de aplicación. [ReadWriteOnce](https://kubernetes.io/docs/concepts/storage/persistent-volumes/) permite el montaje de lectura y escritura por un nodo, no necesariamente por un único Pod. La compatibilidad con ReadWriteMany depende del plugin subyacente o del controlador CSI, y los modos de acceso comunes no aplican por sí mismos la protección de escritura después del montaje. Valide tanto el comportamiento de la plataforma de almacenamiento como el diseño documentado de múltiples instancias de la aplicación.

• Utilice almacenamiento de sistema de archivos compartido solo cuando la aplicación admita el patrón de acceso que requiere.
• Confirme si varias instancias pueden escribir de forma segura en los mismos archivos.
• Especifique la implementación de almacenamiento subyacente, no solo una etiqueta de modo de acceso de Kubernetes.
• Revise el comportamiento de recuperación antes de aprovisionar almacenamiento dinámico; una [StorageClass](https://kubernetes.io/docs/concepts/storage/storage-classes/) puede eliminar el almacenamiento subyacente con una política de recuperación Delete.