Persistent Volumes y Snapshots en Dockup
Persistent volumes y snapshots en Dockup: elige rutas de montaje, inspecciona el uso, crea y programa snapshots, restaura de forma segura y protege los datos persistentes.
Los persistent volumes y snapshots resuelven dos problemas distintos. Un volumen conserva los archivos cuando se reemplaza el contenedor y durante los despliegues. Un snapshot captura el volumen en un momento determinado para que los operadores puedan inspeccionar, conservar o restaurar ese estado más adelante.
El filesystem del contenedor se puede reemplazar. Todo lo que deba sobrevivir a un despliegue —uploads, contenido multimedia generado, índices, artefactos de paquetes o archivos gestionados por la aplicación— necesita una ubicación persistente explícita.
¿Qué datos de la aplicación deben almacenarse en persistent storage?
Usa un volumen cuando la aplicación gestione archivos que no se puedan recrear de forma económica o segura desde otra fuente.
| Datos | ¿Volumen? | Mejor alternativa cuando esté disponible |
|---|---|---|
| Uploads de usuarios | Sí | Object storage si la arquitectura lo utiliza |
| Thumbnails generados | Depende | Regenerarlos a partir de los originales |
| Índice de búsqueda | Depende | Reconstruirlo desde la base de datos de origen |
| Artefactos de build | Normalmente no | Reconstruirlos durante el despliegue |
| Logs de la aplicación | Normalmente no | Sistema de logs del runtime |
| Directorio de datos de PostgreSQL | No como volumen de la aplicación | PostgreSQL gestionado |
| Caché temporal | No | Redis o almacenamiento efímero |
| Base de datos de producción local en SQLite | Arriesgado | Base de datos gestionada para disponer de concurrencia y backups |
Un volumen debe tener un único responsable claro y una ruta de montaje definida. Que dos procesos no relacionados escriban en el mismo directorio dificulta la recuperación y el análisis de permisos.
Antes de añadir almacenamiento, estima el tamaño inicial, la tasa de crecimiento, los requisitos de retención y el objetivo de recuperación. El disco se mide contra el saldo del plan por minuto, por lo que la capacidad sin usar y el crecimiento descontrolado de archivos tienen un coste.
¿Cómo se crea e inspecciona un volumen de Dockup?
Lista los volúmenes existentes del servicio exacto:
dockup volume list production/web --json
Añade un volumen con un nombre, una ruta absoluta del contenedor y un tamaño en gigabytes:
dockup volume add production/web \
--name uploads \
--path /app/uploads \
--size 20 \
--json
La aplicación debe escribir en /app/uploads. Escribir en /uploads o en otro directorio local no redirige mágicamente los datos al montaje.
Después del despliegue, verifica que la aplicación escriba en la ruta absoluta de montaje declarada y no en el filesystem reemplazable del contenedor.
Inspecciona el uso real del disco con el ID de volumen devuelto:
dockup volume usage <volumeId> production/web --json
Compara el uso real con el tamaño asignado y las métricas de la aplicación. Configura alertas antes de que el filesystem se llene; un volumen lleno puede provocar escrituras parciales, uploads fallidos o crashes de la aplicación.
Revisa los requisitos de ownership de los archivos. El usuario del runtime del contenedor debe poder leer y escribir en la ruta de montaje sin conceder permisos más amplios de los necesarios.
¿Cómo protegen los snapshots de volumen los datos?
Un snapshot bajo demanda captura el contenido del volumen:
dockup volume snapshot <volumeId> production/web --json
Lista los snapshots disponibles:
dockup volume snapshots <volumeId> production/web --json
Los snapshots leen el volumen en modo de solo lectura y no requieren que la aplicación escriba en un directorio especial para snapshots. Son útiles antes de una migración de archivos arriesgada, una reescritura masiva de contenido multimedia o un cambio de aplicación que transforme los datos almacenados.
Un snapshot de volumen no es automáticamente consistente con la aplicación. Si la aplicación está escribiendo activamente varios archivos relacionados, el snapshot puede capturarlos en momentos ligeramente distintos. Para una base de datos gestionada, utiliza el sistema de backup de la base de datos gestionada en lugar de crear snapshots de su directorio de datos sin procesar.
Define cuándo debe ponerse la aplicación en estado quiescente. Antes de crear un snapshot de alto valor, puede ser apropiado realizar una breve pausa de mantenimiento o de escritura. Registra el ID del snapshot, el motivo y el punto de restauración esperado.
¿Cómo debe planificarse la retención de snapshots?
Elige el momento de creación y la retención de snapshots a partir de los requisitos de recuperación, no por costumbre. Crea un snapshot bajo demanda antes de cada migración de archivos arriesgada, limpieza o cambio de formato, y registra el ID del snapshot devuelto.
dockup volume snapshot <volumeId> production/web --json
dockup volume snapshots <volumeId> production/web --json
| Necesidad de recuperación | Práctica recomendada para snapshots | Limitación |
|---|---|---|
| Deshacer una migración de archivos | Crear un snapshot inmediatamente antes del cambio | No incluye las escrituras posteriores |
| Conservar puntos históricos | Mantener puntos de recuperación etiquetados según la política | La retención requiere revisiones activas |
| Proteger escrituras frecuentes | Añadir un backup a nivel de aplicación adecuado para los datos | Un snapshot puntual no ofrece protección continua |
| Archivo regulatorio | Usar un flujo de archivo específico | Los snapshots operativos pueden no cumplir la política |
Revisa que los snapshots esperados existan realmente. Una política de retención documentada no demuestra que se haya creado un punto de restauración utilizable.
¿Cómo se restaura un snapshot de volumen de forma segura?
Una restauración reemplaza el contenido actual del volumen y reinicia el contenedor:
dockup volume restore \
<volumeId> \
<snapshotId> \
production/web \
--json
Esta es una operación disruptiva que cambia el estado. Antes de restaurar:
- Confirma el servicio, el ID de volumen y el ID de snapshot exactos.
- Explica qué archivos actuales se reemplazarán.
- Detén o limita las nuevas escrituras siempre que sea posible.
- Crea un snapshot reciente del estado actual si puede llegar a necesitarse.
- Registra la compatibilidad de la aplicación y del esquema.
- Obtén la aprobación explícita para producción.
- Planifica la verificación posterior a la restauración.
Después de la restauración, verifica el estado del contenedor y el comportamiento de la aplicación:
dockup status production/web --json
dockup logs production/web --json
Prueba archivos representativos, permisos, índices y referencias de la aplicación. Que el comando de restauración finalice correctamente demuestra que se ha aplicado el snapshot; no demuestra que cada registro de la aplicación apunte a un archivo válido.
El modelo de guardrails de producción para AI agents debe tratar la restauración como una operación sujeta a aprobación, aunque sea una operación de recuperación.
¿Cómo deben comportarse los volúmenes durante el despliegue y el rollback?
Un despliegue reemplaza los contenedores de la aplicación mientras el volumen montado permanece. Esto permite que una nueva imagen vea los archivos existentes, pero crea una obligación de compatibilidad.
Una nueva versión de la aplicación no debería transformar de forma irreversible los archivos almacenados antes de demostrar que la release funciona. Si cambia los formatos de archivo o la estructura de directorios, utiliza una migración reanudable y compatible con versiones anteriores siempre que sea posible.
El rollback de la aplicación vuelve a ejecutar un despliegue anterior:
dockup deployments production/web -n 20 --json
dockup rollback <deploymentId> production/web --json
El volumen no vuelve automáticamente a un estado anterior junto con la imagen. Es posible que una aplicación antigua no pueda leer los archivos transformados por la nueva versión. Coordina el rollback de la imagen con la restauración de un snapshot solo cuando ambas operaciones sean necesarias y estén aprobadas.
Esta separación es importante:
| Acción de recuperación | ¿Cambia la imagen? | ¿Cambia los datos del volumen? |
|---|---|---|
| Desplegar una nueva versión | Sí | No, salvo que la aplicación los migre |
| Hacer rollback del despliegue | Sí | No |
| Restaurar un snapshot | No | Sí |
| Restaurar y hacer rollback | Sí | Sí |
El proceso de despliegue sin downtime protege el cambio de tráfico, no la compatibilidad de los formatos de datos.
¿Qué incluye un runbook operativo de durable storage?
Asigna un responsable a cada volumen de producción. El runbook debe incluir:
- Target del servicio e ID de volumen.
- Ruta de montaje y usuario de runtime esperado.
- Tamaño asignado y umbral de alerta.
- Descripción de los datos y posibilidad de reconstrucción.
- Schedule de snapshots y retención.
- Último snapshot verificado.
- Política de aprobación de restauraciones.
- Pasos de validación de la aplicación.
- Notas sobre la compatibilidad entre la imagen y los datos.
- Política de crecimiento y eliminación.
Inspecciona el uso periódicamente:
dockup volume usage <volumeId> production/web --json
La CPU, la RAM y el disco se miden por minuto. El plan Free ofrece un crédito inicial de 10 $, mientras que el plan Pro recomendado cuesta 20 $ al mes e incluye 20 $ de crédito de uso.
Simulacro de restauración de snapshots
No esperes a que ocurra un incidente para descubrir que nadie sabe qué snapshot elegir. Ejecuta un simulacro controlado en un servicio que no sea de producción o en una copia aprobada:
- Crea archivos de prueba fácilmente reconocibles.
- Crea un snapshot.
- Modifica los archivos.
- Restaura el snapshot.
- Verifica el contenido y los permisos.
- Observa el reinicio del contenedor.
- Registra los tiempos y los puntos de fallo.
Un simulacro de restauración convierte los persistent volumes y snapshots de una simple casilla de verificación en una capacidad de recuperación probada.
Para el diseño inicial del servicio, consulta Del repositorio Git a producción. Para consultar los detalles de los comandos, utiliza la referencia de Dockup CLI.
Define los objetivos de recuperación de los datos de archivos
El objetivo de punto de recuperación indica cuántos datos recientes puede perder el negocio. El objetivo de tiempo de recuperación indica cuánto puede tardar la restauración. Un snapshot diario con una retención de siete copias puede ser suficiente para una caché interna de contenido multimedia, pero no para un producto de uploads de usuarios que prometa durabilidad casi en tiempo real.
Documenta ambos valores y prueba la duración real de la restauración. La velocidad de creación del snapshot, el tamaño de los datos, el reinicio del contenedor, la validación de archivos y la reindexación de la aplicación contribuyen al tiempo de recuperación.
Controla la eliminación y el crecimiento de archivos
El almacenamiento persistente puede llenarse porque la aplicación nunca elimina los archivos temporales o reemplazados. Añade una política de retención en la capa de aplicación y distingue entre la eliminación lógica y la eliminación física inmediata. Una ventana de recuperación breve puede justificar retrasar la eliminación permanente.
Antes de ejecutar una limpieza masiva:
- Mide el uso actual del volumen.
- Genera una lista de candidatos a eliminación.
- Crea un snapshot.
- Ejecuta la limpieza en batches acotados.
- Verifica las referencias de la aplicación.
- Confirma la recuperación de espacio esperada.
Esto da a los persistent volumes y snapshots un papel preventivo, no solo reactivo ante incidentes.
Verifica el inventario de snapshots
Revisa periódicamente los IDs de snapshot, las horas de creación, la retención y la última prueba de restauración completada correctamente. Un job configurado sin un snapshot utilizable reciente no es un sistema de recuperación.
Asigna la autoridad para restaurar
Define quién puede aprobar una restauración en producción y quién realiza la validación posterior. Separar la aprobación de la ejecución reduce la posibilidad de que la urgencia evite la verificación del destino y del snapshot.
Empieza con un despliegue verificable
Crea un volumen que no sea de producción, toma un snapshot, modifica un archivo de prueba y completa un simulacro de restauración antes de almacenar datos de producción irremplazables.
Empieza gratis en app.dockup.ai. El plan Free cuesta 0 $ al mes, incluye un crédito inicial de 10 $ y permite un workspace, tres bases de datos y tres despliegues.
Preguntas frecuentes
¿Un volumen de Dockup sobrevive a un despliegue?
Sí. El volumen permanece persistente mientras se reemplazan los contenedores del servicio, siempre que la aplicación siga utilizando la ruta de montaje configurada.
¿Es un snapshot de volumen el backup adecuado para PostgreSQL?
No. Un snapshot en caliente de un directorio de datos de una base de datos puede no ser consistente con las transacciones. Para bases de datos gestionadas, es preferible utilizar el sistema de backup de la base de datos gestionada.
¿Qué ocurre cuando se restaura un snapshot de volumen?
El contenido actual del volumen se reemplaza por el snapshot seleccionado y el contenedor se reinicia, por lo que la operación debe aprobarse y verificarse.
¿Puede Dockup programar snapshots de volumen?
Sí. El comando de schedule de volúmenes admite snapshots diarios con un número de copias de retención, y el schedule se puede desactivar explícitamente.
¿Hacer rollback de una aplicación también revierte su volumen?
No. El historial de despliegues de la aplicación y el historial de snapshots del volumen son independientes. Coordina ambos solo cuando el plan de recuperación lo requiera.