Almacenamiento y recuperación
Elige el almacenamiento según los datos que deben sobrevivir a un reinicio del proceso, un nuevo despliegue o un fallo del host. Son eventos diferentes. El almacenamiento persistente no proporciona por sí solo una copia de seguridad, un punto de restauración ni alta disponibilidad.
| Datos | Dónde mantenerla | Límite |
|---|---|---|
| Registros de la aplicación | Managed Postgres u otra base de datos | Un reinicio es distinto de restaurar datos eliminados o dañados. Prueba una ruta independiente de exportación y restauración. |
| Datos de caché y cola | Managed Redis | Decide si la carga de trabajo puede reconstruir su estado o necesita su propio plan de recuperación. Managed Redis no tiene política de expulsión ni archivo append-only: si se queda sin memoria, se reinicia y pueden perderse las escrituras recientes. Guarda en Managed Postgres los datos que no puedas perder. |
| Archivos compartidos por aplicaciones | Managed Object Storage | El bucket default creado automáticamente es privado. Haz público un bucket desde el navegador de buckets del dashboard solo si cualquiera puede leer sus archivos. |
Los archivos de un sandbox siguen otras reglas: solo los archivos de un volumen de Persistent Volumes adjunto en /workspace, o de un snapshot que hayas tomado, sobreviven a un sandbox. Consulta almacenamiento y facturación.
Conservar archivos después de que termine un sandbox
La página Volúmenes del panel permite gestionar volúmenes con nombre y sus conexiones. Adjunta un volumen al crear el sandbox y escribe en /workspace. Detén el sandbox actual antes de adjuntar el volumen a otro.
Para conservar un sandbox entero, memoria incluida, guárdalo con lizard sandbox snapshot <id> y arranca después una copia con lizard sandbox restore <snapshot-id>; consulta snapshots.
Restaurar un recurso eliminado
Un proyecto eliminado queda 3 días en la papelera con sus apps y bases de datos, y lo mismo pasa con una base de datos eliminada. Restáuralos en ese plazo desde Zona de peligro en la configuración del workspace o del proyecto; después, Lizard los elimina para siempre.
- Una app que eliminas por separado solo va a la papelera si la desplegaste desde archivos con
lizard up; al restaurarla, se vuelve a compilar desde esa subida. Una app desplegada desde GitHub se elimina al instante. - Los sandboxes, sus volúmenes y sus snapshots no tienen papelera. Si los eliminas a ellos o al proyecto al que pertenecen, desaparecen al instante.
- Eliminar un workspace tampoco tiene papelera.
Planificar una restauración de base de datos
Antes de una migración o una versión que cambie datos:
- Elige un método de exportación para la base de datos y la versión en uso.
- Almacena la exportación por separado del recurso que se va a cambiar.
- Restaura en una base de datos de prueba independiente y verifica que la aplicación pueda leerla.
- Registra la duración de la restauración y los datos más recientes incluidos en la exportación.
No asumas copias de seguridad programadas, recuperación a un momento dado, replicación multinodo ni una garantía de tiempo de restauración por el hecho de que la base de datos sea administrada. Confirma el acuerdo de servicio actual y los controles disponibles para tu recurso.
Referencias de entorno
Una aplicación debe leer su conexión a la base de datos desde una referencia de entorno. Una cadena de conexión es una credencial; evita imprimirla para verificar una actualización. Una comprobación de conexión como SELECT 1 demuestra más que ver la variable en un shell.
Guías relacionadas
- Managed Postgres
- Managed Redis
- Managed Object Storage
- Persistent Volumes
- Recuperación de despliegues
Actualizado