Tutorial de n8n: copias de seguridad, restauración y actualización de versiones

Qué debes respaldar

Método 1: exportar flujos de trabajo con la CLI

n8n incluye comandos de exportación que permiten exportar los flujos de trabajo como archivos JSON (adecuados para guardar en Git y controlar las versiones):

docker compose exec n8n n8n export:workflow --all --separate --output=/home/node/.n8n/backup/workflows/
docker compose exec n8n n8n export:credentials --all --separate --output=/home/node/.n8n/backup/credentials/

• --separate: crea un archivo por cada flujo de trabajo
• Las credenciales exportadas siguen cifradas de forma predeterminada; para usarlas necesitas la misma clave de cifrado

Copia los archivos fuera del contenedor:

docker compose cp n8n:/home/node/.n8n/backup ./n8n-backup-$(date +%F)

Para restaurar:

docker compose exec n8n n8n import:workflow --separate --input=/home/node/.n8n/backup/workflows/
docker compose exec n8n n8n import:credentials --separate --input=/home/node/.n8n/backup/credentials/

Método 2: hacer una copia de seguridad de la base de datos

PostgreSQL

docker compose exec -T postgres pg_dump -U n8n n8n | gzip > n8n-db-$(date +%F).sql.gz

Para restaurar (en una base de datos nueva):

gunzip -c n8n-db-2026-10-12.sql.gz | docker compose exec -T postgres psql -U n8n -d n8n

SQLite

La base de datos SQLite está en el Volume n8n_data (database.sqlite). Antes de hacer la copia de seguridad, detén n8n para evitar copiar un archivo mientras se está escribiendo:

docker compose stop n8n
docker run --rm -v n8n_n8n_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/n8n-data-$(date +%F).tar.gz -C /data .
docker compose start n8n

(El nombre del Volume es «nombre_del_proyecto_n8n_data»; puedes comprobarlo con docker volume ls.)

Copias de seguridad automatizadas

Usa cron para crear una copia de seguridad diaria y sincroniza el archivo con otro destino (otro host o almacenamiento en la nube):

# /etc/cron.daily/n8n-backup
#!/bin/sh
cd /opt/n8n
docker compose exec -T postgres pg_dump -U n8n n8n | gzip > /backup/n8n-$(date +%F).sql.gz
find /backup -name 'n8n-*.sql.gz' -mtime +30 -delete

Prueba restaurar las copias de seguridad con regularidad para confirmar que funcionan.

Migrar a un host nuevo

1. En el host antiguo, haz una copia de seguridad de la base de datos y de .env (incluida N8N_ENCRYPTION_KEY).
2. En el host nuevo, inicia PostgreSQL con el mismo compose.yaml y .env.
3. Restaura la base de datos.
4. Inicia n8n y confirma que los flujos de trabajo y las credenciales funcionan correctamente.
5. Actualiza el DNS para que apunte al host nuevo.

Actualizar n8n

n8n publica versiones nuevas aproximadamente cada semana. Este es el proceso recomendado:

1. Lee las notas de la versión (Release notes), sobre todo para comprobar si hay cambios incompatibles (breaking changes).

2. Haz una copia de seguridad.

3. Cambia la versión de la imagen en compose.yaml, por ejemplo, de n8nio/n8n:2.42.7 a la nueva versión.

4. Actualiza:

   docker compose pull n8n
   docker compose up -d n8n
   docker compose logs -f n8n

5. Comprueba que los flujos de trabajo importantes funcionen correctamente.

Al iniciar n8n, se ejecutan automáticamente las migraciones de la base de datos. Puedes ver su progreso en los registros.

Etiquetas de versión

Etiquetas de imagen de n8n 2.x:

Actualizar de n8n 1.x a 2.x

La versión 2.0 incluye varios cambios incompatibles. Antes de actualizar, lee la documentación oficial sobre los breaking changes de 2.0. Entre los cambios principales están:

• El interruptor Activate se reemplazó por Publish / Unpublish: guardar no aplica los cambios de inmediato; debes publicarlos.
• Los ejecutores de tareas (task runners) están activados de forma predeterminada; el nodo Code se ejecuta en un proceso independiente.
• El nodo Code no puede leer variables de entorno de forma predeterminada; debes adaptar las partes de los flujos antiguos que usan $env.
• El nodo Python Code ahora usa Python nativo y requiere un ejecutor de tareas externo; la sintaxis es distinta de la de la versión anterior.
• La ejecución de comandos del sistema (Execute Command) y el activador de archivos locales están desactivados de forma predeterminada.
• Los nodos de lectura y escritura de archivos solo pueden acceder a carpetas específicas de forma predeterminada.
• Ya no se admite MySQL / MariaDB como base de datos de n8n; primero debes migrar a PostgreSQL o SQLite.
• Los datos que un subflujo devuelve al flujo principal ahora son la salida del último nodo del subflujo.
• Se eliminó el nodo Start; usa Manual Trigger en su lugar.

Te recomendamos probar primero la versión 2.x en un entorno de pruebas con datos de una copia de seguridad. Cuando confirmes que los flujos de trabajo importantes funcionan correctamente, actualiza el entorno de producción.

Actualizado 12 de octubre de 2026