Copias de seguridad y restauración#

Todo lo de Empowerment Center está en la BD propia. Esta página explica cómo copiarla con las herramientas de PostgreSQL, qué hay que guardar además de la copia, cómo restaurarla y qué son las copias que ECenter guarda por su cuenta de los libros, las plantillas y el metadata.

Qué hay que copiar#

Qué	Dónde	Cómo
La BD propia	El volumen `db-data` del servicio `db`, o el servidor PostgreSQL	Con `pg_dump` o con copia continua (abajo).
`ECENTER_SECRETS_KEY`	`deploy/.env`	Aparte, en un gestor de secretos o una caja fuerte.
La configuración	`deploy/.env` y el `application.yml` propio	Aparte, con la misma protección que la clave.

La BD propia guarda el metadata, la seguridad, los libros con sus copias, las listas, las agrupaciones, las publicaciones y las plantillas del portal, las capas geográficas, las tareas programadas, las suscripciones y alertas, las credenciales de servicio, las sesiones, la auditoría y la licencia.

Atención

Sin ECENTER_SECRETS_KEY, una copia de la BD se restaura pero las contraseñas de las conexiones no se pueden descifrar y hay que volver a escribirlas todas. Y quien tenga la copia y la clave tiene esas contraseñas: guarde las dos con la misma protección, pero no juntas.

Lo que no está en la copia#

ECENTER_SECRETS_KEY, el fichero .env y el application.yml propio, que se guardan aparte.
Las BD de los clientes, que tienen su propia copia. Las tablas de trabajo que ECenter crea en ellas (listas, agrupaciones, datos externos) se vuelven a llenar al renovarlas o al usarlas.
Los trabajos en curso y sus resultados, que viven en la memoria del backend: tras restaurar, los usuarios vuelven a calcular.
El grafo del motor de rutas, que se reconstruye solo.

Copiar la BD propia#

Con la instalación de ejemplo de Docker Compose, la copia se hace con el superusuario de la BD desde dentro de su contenedor, con la aplicación en marcha (pg_dump da una copia coherente aunque se esté usando):

docker compose -f deploy/compose.yaml exec -T db \
  pg_dump -U postgres -Fc ecenter > ecenter-$(date +%F).dump

El fichero resultante está comprimido (-Fc) y se restaura con pg_restore. Programe la copia a diario con el planificador del sistema y guarde varias, fuera del servidor.

Nota

Haga la copia con el superusuario (postgres), como en el ejemplo. El usuario ecenter no puede leer las tablas que la imagen de PostGIS crea para sus extensiones auxiliares, y pg_dump con él falla con «permission denied for schema tiger». El superusuario no tiene contraseña: solo entra desde dentro del contenedor, como en el ejemplo.

Con mucha actividad, mejor una copia continua (el archivado del WAL de PostgreSQL, con recuperación a un momento dado) o la del servicio gestionado, si la BD propia está en uno. En un servicio gestionado, use su copia o haga pg_dump con un usuario que pueda leer todas las tablas de la base de datos.

Restaurar la BD propia#

Para volver a una copia, en el mismo servidor o en otro:

Pare el backend, para que nadie escriba durante la restauración:
```
docker compose -f deploy/compose.yaml stop backend
```

Borre la base de datos y créela vacía, con ecenter como dueño:

docker compose -f deploy/compose.yaml exec -T db dropdb -U postgres ecenter
docker compose -f deploy/compose.yaml exec -T db createdb -U postgres -O ecenter ecenter

Restaure la copia con el superusuario, que crea también las extensiones:

docker compose -f deploy/compose.yaml exec -T db \
  pg_restore -U postgres -d ecenter < ecenter-2026-09-29.dump

Arranque el backend:

docker compose -f deploy/compose.yaml start backend

Las tablas restauradas conservan como dueño a ecenter. Al arrancar, el backend aplica las migraciones que falten si la copia es de una versión anterior.

En otro servidor, prepare antes la instalación (los pasos 1 y 2 de Instalar con Docker Compose) con la misma ECENTER_SECRETS_KEY que la instalación de origen, arranque solo la BD (docker compose -f deploy/compose.yaml up -d db) y siga los pasos anteriores.

Importante

Restaurar sustituye todo: lo que se hizo después de la copia (libros guardados, usuarios dados de alta, auditoría) se pierde. Antes de restaurar, haga una copia de lo que hay ahora.

Después de restaurar#

La licencia viaja con la copia: va en la BD propia con el identificador de la instalación. Si restaura en otro servidor y el antiguo sigue en uso, cada uno necesita su licencia.
Las sesiones también están en la copia, pero casi siempre habrán caducado (30 minutos sin uso): los usuarios vuelven a entrar.
Las ejecuciones programadas que estaban en marcha en el momento de la copia se dan por interrumpidas al arrancar.
Si ECENTER_SECRETS_KEY no es la misma, Administración › Conexiones enseña en cada conexión «La contraseña guardada no se puede descifrar: vuelva a introducirla.». Pulse Cambiar contraseña… en cada una.

Las copias que guarda ECenter#

Además de la copia de la BD, ECenter guarda por su cuenta copias que sirven para deshacer un cambio, no para recuperar la instalación. Todas están en la BD propia, así que entran en su copia:

Copias	Cuándo se hacen	Dónde se restauran
De cada libro	Al guardarlo, de lo que había antes.	Con Copias de seguridad… del libro (véase el Manual de usuario).
De cada plantilla del portal	Al guardarla, de lo que había antes.	Con Copias de seguridad… de la plantilla.
Del metadata de cada conexión	Antes de cada importación sobre una conexión con metadata, antes de cada restauración y a petición.	Con Copias de seguridad… en Administración › Metadata (véase Metadata).

De cada una se conservan las 10 últimas de hoy y la última de cada uno de los 7 días anteriores. Se cambia en ecenter.workbooks.backups-*, ecenter.portal.layouts.backups-* y ecenter.metadata.backups-* (véase Operación, auditoría y planificación).

Exportar el metadata de una conexión como paquete sirve para llevarlo de un entorno a otro (de desarrollo a producción) o para guardarlo en un repositorio, no para recuperar una instalación: no lleva usuarios, conexiones ni nada propio de la instalación. Véase Metadata.