Actualizar y hacer copias de seguridad de la aplicación

Esta página está dirigida al administrador técnico de una instancia de MyZapp instalada en sus propios servidores (ver «Instalar la aplicación en tus propios servidores»). En una instancia alojada por el editor, el alojador se encarga de las copias de seguridad y de las actualizaciones.

Qué hay que guardar

Una instancia solo guarda su estado en dos lugares:

• la base de datos PostgreSQL: todos los datos y toda la configuración;
• el volumen de datos de la aplicación: su configuración local (con los secretos cifrados), los registros y los archivos subidos.

Los contenedores en sí no contienen nada que guardar: se vuelven a crear idénticos a partir de la imagen. Guarda también, aparte, los archivos del servidor: .env, la carpeta secrets/ y, si se usa, la carpeta views-override/. Conserva las claves de seguridad exportadas en la instalación con el mismo cuidado.

Hacer una copia de seguridad

El script backup.sh, entregado con la aplicación, produce con una sola orden:

• un volcado de la base, db_ seguido de la fecha, en el formato de pg_restore (no es un archivo SQL legible);
• un archivo comprimido del volumen de datos, appdata_ seguido de la fecha.

Ejecútalo desde la carpeta del archivo de orquestación: ./backup.sh .env ./backups. Conserva las 10 últimas copias de cada tipo; BACKUP_RETENTION_COUNT en .env cambia ese número.

Opcionalmente, configurables en .env:

• el cifrado de las copias (BACKUP_ENCRYPT=true, con contraseña o con clave pública GPG);
• una copia externa hacia uno o varios destinos: FTP, almacenamiento compatible con S3, recurso compartido de Windows, recurso ya montado o servidor accesible por SSH (BACKUP_OFFSITE_TYPES). Por defecto, el fallo de una copia externa es solo un aviso; BACKUP_OFFSITE_REQUIRED=true lo convierte en error.

La aplicación no ejecuta este script por sí sola: prográmalo en el servidor, por ejemplo cada noche con cron. La lista completa de parámetros figura al principio del script.

Restaurar

El mismo procedimiento sirve tras un incidente y para reconstruir una instancia en un servidor nuevo.

1. Arranca solo la base de datos y detén la aplicación, para que no se aplique ninguna migración durante la restauración.
2. Si las copias están cifradas, descífralas primero.
3. Restaura la base con pg_restore y las opciones --clean --if-exists, en el contenedor webbase-postgres.
4. Restaura el volumen de datos a partir de su archivo comprimido: su contenido actual se sustituye.
5. Vuelve a arrancar el conjunto y comprueba que /health responde Healthy.

Una base restaurada en otra instalación (por ejemplo, una producción copiada en pruebas) puede mostrar una identidad en conflicto en la página Licencias: elige entonces entre instancia nueva e instancia trasladada (ver «Gestionar las licencias de la instancia»).

Actualizar la versión

1. Haz una copia de seguridad: una actualización no prevé ninguna vuelta atrás automática.
2. Carga la nueva imagen (docker load para un archivo) o indica su versión en WEBBASE_IMAGE, en .env.
3. Con un registro, descarga la nueva imagen: docker compose -f docker-compose.onprem-client.yml pull.
4. Vuelve a arrancar: docker compose -f docker-compose.onprem-client.yml up -d. Los datos se conservan.

Al arrancar, cada módulo aplica sus propias migraciones de base de datos. Comprueba después:

• la pantalla Estado de la instancia, que muestra la nueva versión, y la pantalla Diagnóstico de soporte, que debe indicar Al día para cada módulo (ver «Supervisar la instancia»);
• el Registro de cambios, que enumera las novedades de la versión instalada;
• la documentación entregada con la versión, que hay que volver a importar (ver «Actualizar la documentación»).

Lee las notas de la versión antes de actualizar: algunas piden un paso más, por ejemplo copiar un nuevo archivo de orquestación.

Una vista personalizada debe estar en views-override/: es el único lugar que se conserva de una versión a otra.

Si la actualización falla

Si una migración falla, la aplicación no arranca y la base puede quedar en un estado intermedio. Para volver a la versión anterior:

1. restaura la copia hecha justo antes de la actualización (ver más arriba);
2. vuelve a poner la versión anterior en WEBBASE_IMAGE;
3. vuelve a arrancar.

Volver a poner solo la imagen anterior no basta cuando la nueva versión ya ha migrado la base: las migraciones aplicadas no se deshacen. La imagen anterior sigue disponible en el servidor mientras no se haya borrado.

Cambiar de versión de PostgreSQL

Una nueva versión mayor de PostgreSQL no lee los archivos de datos de la anterior: cambiar solo la imagen de la base no funciona. Hace falta un volcado completo, una base nueva en la nueva versión y después la restauración del volcado. Conserva una imagen que incluya la extensión pgvector, usada por la base de conocimientos: sin ella, la restauración falla.

Ver también

• «Instalar la aplicación en tus propios servidores».
• «Supervisar la instancia»: versión, estado de la base, módulos y migraciones.
• «Cambiar la conexión a la base de datos».