Copia de seguridad y restauración

Lo que mantiene tus datos en una instalación de Conzent OCI autoalojada, cómo hacer una copia de seguridad programada y cómo restaurarla en un nuevo servidor.

Copia de seguridad y restauración

Todo lo que Conzent almacena vive en volúmenes de Docker y un archivo de configuración. Esta página cubre qué vale la pena respaldar, cómo automatizarlo y cómo recuperar todo.

Qué es lo que realmente sostiene tus datos

Docker Compose crea cinco volúmenes nombrados. Solo dos contienen algo que no puedes reconstruir.

Volumen / archivo Contenido ¿Hacer copia de seguridad?
oci-db-data MariaDB: sitios, banners, registros de consentimiento, categorías de cookies, políticas, usuarios, resultados de escaneo Sí — esto es todo
app-sites-data Scripts de consentimiento generados Sí, aunque regenerables
.env Contraseña de la base de datos, clave del escáner, credenciales de terceros Sí — irremplazable
app-public Activos CSS/JS construidos No — reconstruidos desde la imagen
app-var Caché y registros No
oci-redis-data Sesiones, cola de trabajos, búfer de balizas No — transitorio por diseño

scripts/backup.sh captura exactamente los primeros tres, además de .conzent-credentials si aún existe.

Los scripts de consentimiento están incluidos porque restaurarlos mantiene los banners en vivo funcionando durante los minutos entre una restauración y una regeneración — pero no son la fuente de verdad. Si se perdieran por completo, php bin/oci scripts:regenerate reconstruye cada uno desde la base de datos.

Tomando una copia de seguridad

bash scripts/backup.sh

Eso escribe backups/conzent-YYYYmmdd-HHMMSS.tar.gz que contiene el volcado completo de la base de datos, los scripts de consentimiento generados, tu .env, y un manifiesto que registra cuándo se tomó y de qué APP_URL.

bash scripts/backup.sh --output /mnt/backups     # escribir en otro lugar
bash scripts/backup.sh --keep 14                 # mantener solo los 14 archivos más nuevos

El volcado utiliza --single-transaction, por lo que las tablas InnoDB se capturan de manera consistente sin bloquear escrituras. No es necesario detener la aplicación primero.

El archivo contiene tu base de datos y tus secretos. Se escribe en modo 600. Trátalo como un archivo de contraseña: guárdalo fuera del servidor y encripta si aterriza en algún lugar compartido.

Automatizándolo

Una copia de seguridad nocturna a las 03:00, manteniendo dos semanas:

0 3 * * * cd /path/to/conzent && /bin/bash scripts/backup.sh --keep 14 >> /var/log/conzent-backup.log 2>&1

Usa la ruta absoluta a tu directorio de instalación — cron no hereda el directorio de trabajo de tu shell.

Una copia de seguridad en el mismo disco que la base de datos no es una copia de seguridad. Agrega un paso fuera del sitio:

15 3 * * * rsync -az /path/to/conzent/backups/ backup-host:/srv/conzent-backups/

Encripta antes de que salga si el destino no es tuyo: gpg --symmetric --cipher-algo AES256 backups/conzent-....tar.gz.

Restaurando

bash scripts/restore.sh backups/conzent-20260722-030000.tar.gz --yes

--yes es obligatorio — la restauración reemplaza la base de datos actual por completo. Lo que hace, en orden:

  1. Descomprime y valida el archivo, imprimiendo su manifiesto.
  2. Detiene los contenedores de la aplicación, dejando MariaDB en funcionamiento.
  3. Importa el volcado en la base de datos nombrada en tu actual .env.
  4. Restaura el volumen de scripts de consentimiento.
  5. Reinicia todo.
  6. Ejecuta migrations:migrate, para que un archivo antiguo se actualice al esquema que esta versión espera.
  7. Ejecuta scripts:regenerate, para que los scripts se reconstruyan contra tu actual APP_URL, no la que está en el archivo.
  8. Vacía Redis.

Los pasos 6 y 7 son la razón por la que una copia de seguridad tomada en old-domain.com se restaura limpiamente en una instalación que ahora sirve consent.example.com.

Por defecto, tu .env existente se deja intacto. Para tomar también la versión del archivo, agrega --restore-env; tu archivo anterior se guarda como .env.before-restore-<timestamp>. Usa eso al reconstruir un servidor perdido, no al revertir datos en uno que funciona — la DB_PASSWORD archivada no coincidirá con una base de datos recién inicializada.

Reconstruyendo un servidor desde cero

# 1. Instalación nueva en la nueva máquina
curl -sSL https://getconzent.com/install | sh -s -- --domain consent.example.com

# 2. Copia el archivo
scp backups/conzent-20260722-030000.tar.gz newhost:/root/conzent/

# 3. Restaura datos y configuración
cd /root/conzent
bash scripts/restore.sh conzent-20260722-030000.tar.gz --yes --restore-env

# 4. Si el dominio cambió, configúralo y regenera
sed -i 's|^APP_URL=.*|APP_URL=https://consent.example.com|' .env
docker compose up -d
docker compose exec app php bin/oci scripts:regenerate

Realiza un simulacro de restauración

Una copia de seguridad no probada es una suposición. Haz esto una vez, antes de necesitarlo:

  1. Anota un nombre de sitio, su configuración de banner y el conteo de registros de consentimiento de hoy.
  2. Toma una copia de seguridad.
  3. En una máquina o VM separada, instala desde cero y restaura el archivo.
  4. Inicia sesión y confirma que el sitio, la configuración del banner y los registros de consentimiento estén todos allí.
  5. Carga una página que contenga la incrustación de ese sitio y verifica que el banner aún se renderiza.

Diez minutos ahora, en lugar de descubrir la brecha durante un incidente.

Antes de cada actualización

Las actualizaciones preservan tu base de datos, pero haz una copia de seguridad primero de todos modos — una migración es lo único que una restauración no puede deshacer:

bash scripts/backup.sh --keep 14 && bash scripts/install.sh --update

La referencia completa vive con el código: docs/backup-restore.md en GitHub.

Volver a la Documentación