Copia de seguridad y actualización de n8n en producción (Docker Compose + PostgreSQL)

14 min de lectura·Matthieu·n8ndocker-composepostgresqlbackupdisaster-recovery|

Guía de operaciones del día dos para n8n autoalojado: copias de seguridad PostgreSQL automatizadas, protección de la clave de cifrado, copias externas con rclone, recuperación ante desastres desde un VPS nuevo, actualizaciones seguras con Docker Compose, rollback y migración de 1.x a 2.x.

Ya tienes n8n funcionando en tu VPS con Docker Compose y PostgreSQL. Eso fue el día uno. El día dos consiste en mantenerlo vivo: copias de seguridad automatizadas, restauraciones probadas y actualizaciones seguras.

Esta guía cubre lo que necesitas para proteger una instancia n8n en producción. Construiremos un script de backup, lo automatizaremos con cron, copiaremos las copias de seguridad fuera del servidor, haremos una recuperación ante desastres en un VPS nuevo y actualizaremos n8n de forma segura con soporte de rollback. También cubrimos la migración de 1.x a 2.x.

Esta guía asume que seguiste nuestra guía de instalación de n8n con Docker Compose para configurar n8n. Tu stack usa Docker Compose con PostgreSQL, un usuario deploy sin privilegios de root y un reverse proxy.

¿Qué datos almacena n8n que necesitan respaldo?

n8n almacena cinco componentes que debes respaldar juntos. Si falta cualquiera de ellos, la restauración puede ser parcial o imposible. La base de datos PostgreSQL contiene tus workflows, credenciales (cifradas), historial de ejecución y cuentas de usuario. La clave de cifrado (encryption key) descifra esas credenciales. El volumen Docker almacena nodos personalizados y datos binarios. Tus archivos .env y docker-compose.yml definen la configuración de ejecución.

Componente Contenido Riesgo si se pierde Método de backup
Base de datos PostgreSQL Workflows, credenciales cifradas, historial de ejecución, usuarios Todos los datos perdidos pg_dump (formato custom)
N8N_ENCRYPTION_KEY Clave AES-256 para descifrar credenciales Todas las credenciales guardadas se vuelven irrecuperables permanentemente Copiar desde .env o configuración del contenedor
Volumen Docker (.n8n) Nodos personalizados, datos binarios de ejecución Nodos personalizados y archivos subidos perdidos Contenedor Alpine con tar
Archivo .env Contraseñas de base de datos, clave de cifrado, configuración de dominio Debe recrearse manualmente Copia de archivo
docker-compose.yml Definiciones de servicios, mapeo de volúmenes, tags de imágenes Debe recrearse manualmente Copia de archivo

¿Cómo respaldar la base PostgreSQL de n8n con pg_dump?

Usa pg_dump con --format=custom para crear un dump comprimido y restaurable de la base n8n. El formato custom soporta restauración selectiva y procesamiento paralelo. Ejecuta el dump a través del contenedor PostgreSQL en ejecución.

docker exec n8n-postgres \
  pg_dump -U n8n -d n8n --format=custom \
  > /home/deploy/n8n-backups/n8n-db-$(date +%Y%m%d-%H%M%S).dump

Qué hace este comando: docker exec ejecuta pg_dump dentro del contenedor PostgreSQL. -U n8n es el usuario de la base. -d n8n es el nombre de la base. --format=custom produce un dump binario comprimido que pg_restore puede restaurar selectivamente. La salida se redirige a un archivo con marca de tiempo en el host.

Verifica que el dump sea válido:

cat /home/deploy/n8n-backups/n8n-db-*.dump | docker exec -i n8n-postgres pg_restore --list | head -20

Como pg_restore está dentro del contenedor PostgreSQL, el dump se envía por pipe a docker exec -i. Deberías ver una lista de objetos de base de datos (tablas, secuencias, datos). Si ves un error o salida vacía, el dump falló.

Respaldar el volumen Docker

El volumen de datos de n8n contiene nodos personalizados y datos binarios de ejecución. Respáldalo con un contenedor Alpine temporal:

docker run --rm \
  -v n8n_n8n_data:/source:ro \
  -v /home/deploy/n8n-backups:/backup \
  alpine tar czf "/backup/n8n-data-$(date +%Y%m%d-%H%M%S).tar.gz" -C /source .

El nombre del volumen n8n_n8n_data se compone del nombre del proyecto Docker Compose (n8n, del directorio) más el nombre del volumen (n8n_data, de docker-compose.yml). Ejecuta docker volume ls si el tuyo es diferente.

Qué hace este comando: Monta el volumen de datos n8n como solo lectura (:ro) en un contenedor Alpine desechable. El contenedor crea un archivo comprimido del contenido del volumen y lo escribe en el directorio de backup. El contenedor se elimina al terminar (--rm).

Verifica el archivo:

tar tzf /home/deploy/n8n-backups/n8n-data-*.tar.gz | head -10

Deberías ver rutas de archivos del directorio .n8n.

Respaldar archivos de configuración

BACKUP_DIR="/home/deploy/n8n-backups"
TIMESTAMP=$(date +%Y%m%d-%H%M%S)
cp /home/deploy/n8n/.env "$BACKUP_DIR/env-$TIMESTAMP.bak"
cp /home/deploy/n8n/docker-compose.yml "$BACKUP_DIR/docker-compose-$TIMESTAMP.yml.bak"
chmod 600 "$BACKUP_DIR/env-$TIMESTAMP.bak"

El archivo .env contiene tu N8N_ENCRYPTION_KEY y la contraseña de la base de datos. Restringe los permisos a 600 para que solo el usuario de backup pueda leerlo.

¿Por qué la clave de cifrado de n8n es el backup más importante?

n8n cifra cada credencial guardada (claves API, tokens OAuth, contraseñas de bases de datos) con AES-256 usando la N8N_ENCRYPTION_KEY. Si pierdes esta clave, cada credencial en tu base de datos se vuelve irrecuperable de forma permanente. No hay mecanismo de reseteo. No hay puerta trasera. Tendrías que volver a introducir manualmente cada credencial en cada workflow.

La clave se define explícitamente en tu archivo .env o se genera automáticamente por n8n en el primer inicio y se almacena dentro del contenedor en /home/node/.n8n/config.

Encuentra tu clave de cifrado:

Si la definiste en .env:

grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env

Si n8n la generó automáticamente (nunca la definiste explícitamente):

docker exec n8n cat /home/node/.n8n/config

Busca el campo encryptionKey en la salida JSON.

Almacena la clave de forma segura:

  1. Copia el valor de la clave a un gestor de contraseñas (Bitwarden, KeePass, 1Password).
  2. Asegúrate de que existe en tu archivo .env como N8N_ENCRYPTION_KEY=<tu-clave>.
  3. Tu script de backup ya copia .env, pero almacena la clave por separado también. Si tu servidor se destruye y tus backups están corruptos, aún podrás recrear credenciales si tienes la clave.

¿Cómo automatizar las copias de seguridad de n8n con cron?

Combina el dump de la base, el backup del volumen y la copia de configuración en un solo script. Añade limpieza por retención y un ping de health check para detectar fallos.

Crea el script de backup:

nano /home/deploy/n8n/backup-n8n.sh

#!/usr/bin/env bash
set -euo pipefail

# --- Configuration ---
BACKUP_DIR="/home/deploy/n8n-backups"
N8N_DIR="/home/deploy/n8n"
COMPOSE_PROJECT="n8n"
DB_CONTAINER="n8n-postgres"  # Matches container_name in docker-compose.yml
DB_USER="n8n"
DB_NAME="n8n"
VOLUME_NAME="${COMPOSE_PROJECT}_n8n_data"  # docker compose prefixes project name
RETENTION_DAYS=7
RETENTION_WEEKS=4
HEALTHCHECK_URL=""  # Set to your healthcheck.io or uptime-kuma URL

TIMESTAMP=$(date +%Y%m%d-%H%M%S)
DAY_OF_WEEK=$(date +%u)

mkdir -p "$BACKUP_DIR/daily" "$BACKUP_DIR/weekly"

# --- PostgreSQL dump ---
echo "[$(date)] Starting PostgreSQL backup..."
docker exec "$DB_CONTAINER" \
  pg_dump -U "$DB_USER" -d "$DB_NAME" --format=custom \
  > "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump"

# Verify dump is not empty
if [ ! -s "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump" ]; then
  echo "[$(date)] ERROR: Database dump is empty!" >&2
  exit 1
fi

# --- Docker volume backup ---
echo "[$(date)] Starting volume backup..."
docker run --rm \
  -v "${VOLUME_NAME}:/source:ro" \
  -v "$BACKUP_DIR/daily:/backup" \
  alpine tar czf "/backup/n8n-data-$TIMESTAMP.tar.gz" -C /source .

# --- Config files ---
echo "[$(date)] Backing up config files..."
cp "$N8N_DIR/.env" "$BACKUP_DIR/daily/env-$TIMESTAMP.bak"
cp "$N8N_DIR/docker-compose.yml" "$BACKUP_DIR/daily/docker-compose-$TIMESTAMP.yml.bak"
chmod 600 "$BACKUP_DIR/daily/env-$TIMESTAMP.bak"

# --- Weekly copy (Sundays) ---
if [ "$DAY_OF_WEEK" -eq 7 ]; then
  echo "[$(date)] Creating weekly backup copy..."
  cp "$BACKUP_DIR/daily/n8n-db-$TIMESTAMP.dump" "$BACKUP_DIR/weekly/"
  cp "$BACKUP_DIR/daily/n8n-data-$TIMESTAMP.tar.gz" "$BACKUP_DIR/weekly/"
  cp "$BACKUP_DIR/daily/env-$TIMESTAMP.bak" "$BACKUP_DIR/weekly/"
fi

# --- Retention cleanup ---
echo "[$(date)] Cleaning old backups..."
find "$BACKUP_DIR/daily" -type f -mtime +$RETENTION_DAYS -delete
find "$BACKUP_DIR/weekly" -type f -mtime +$((RETENTION_WEEKS * 7)) -delete

# --- Health check ping ---
if [ -n "$HEALTHCHECK_URL" ]; then
  curl -fsS --retry 3 "$HEALTHCHECK_URL" > /dev/null
fi

echo "[$(date)] Backup complete."

Establece los permisos y prueba:

chmod 750 /home/deploy/n8n/backup-n8n.sh

/home/deploy/n8n/backup-n8n.sh

Verifica que se crearon los archivos de backup:

ls -lh /home/deploy/n8n-backups/daily/

Revisa los tamaños de archivo. Un dump típico de base n8n pesa entre 500 KB y 50 MB dependiendo del historial de ejecución. Si el dump pesa 0 bytes, algo salió mal.

Programar con cron

crontab -e

Añade esta línea para ejecutar backups diariamente a las 03:00:

0 3 * * * /home/deploy/n8n/backup-n8n.sh >> /home/deploy/n8n-backups/backup.log 2>&1

Qué hace este comando: Ejecuta el script de backup a las 3 de la mañana cada día. La salida y los errores se agregan a backup.log para diagnosticar fallos.

Alertas de fallo de backup

La variable HEALTHCHECK_URL en el script es compatible con servicios como Healthchecks.io o una instancia autoalojada de Uptime Kuma. Estos servicios esperan un ping a intervalos regulares. Si el ping se detiene (porque el script falló o el cron no se ejecutó), recibes una alerta.

Configura un check con un período de 24 horas y una tolerancia de 1 hora. Si el script de backup no envía ping antes de las 04:00, recibirás una notificación.

¿Cómo copiar los backups de n8n fuera del servidor con rclone?

Las copias de seguridad en el mismo servidor que n8n no son backups reales. Si el disco falla, pierdes ambos. Usa rclone para copiar los backups a almacenamiento de objetos compatible con S3 (Wasabi, Backblaze B2, MinIO o cualquier proveedor S3).

Instala rclone:

sudo apt install rclone

Configura un remoto. Este ejemplo usa cualquier almacenamiento compatible con S3:

rclone config

Sigue las indicaciones interactivas para crear un remoto llamado n8n-backup. Elige "Amazon S3 Compliant Storage Providers" e introduce tu endpoint, clave de acceso y clave secreta.

Verifica que el remoto funciona:

rclone lsd n8n-backup:

Deberías ver tu bucket en la lista.

Añade la sincronización a tu script de backup. Inserta esto antes de la línea del ping de health check:

# --- Off-server copy ---
echo "[$(date)] Syncing to remote storage..."
rclone sync "$BACKUP_DIR" n8n-backup:your-bucket-name/n8n \
  --transfers 4 \
  --min-age 1m \
  --log-level ERROR

--min-age 1m evita subir archivos que aún se están escribiendo. --transfers 4 ejecuta cuatro subidas en paralelo.

¿Cómo verificar que los backups de n8n son válidos?

Un backup que nunca has probado es un backup que no tienes. Ejecuta estas comprobaciones periódicamente.

Integridad del dump de base de datos:

cat /home/deploy/n8n-backups/daily/n8n-db-*.dump | docker exec -i n8n-postgres pg_restore --list > /dev/null 2>&1 && echo "OK" || echo "CORRUPT"

Integridad del archivo del volumen:

tar tzf /home/deploy/n8n-backups/daily/n8n-data-*.tar.gz > /dev/null 2>&1 && echo "OK" || echo "CORRUPT"

Checksums para verificación remota:

Genera checksums después del backup:

sha256sum /home/deploy/n8n-backups/daily/* > /home/deploy/n8n-backups/daily/checksums.sha256

Después de descargar desde el almacenamiento remoto, verifica:

sha256sum -c checksums.sha256

Cada línea debería decir OK. Cualquier discrepancia significa que el archivo se corrompió durante la transferencia.

¿Cómo restaurar n8n desde un backup en un VPS nuevo?

Este es el procedimiento de recuperación ante desastres. Perdiste tu servidor. Tienes un VPS nuevo y tus archivos de backup (desde almacenamiento remoto o copia local). Así es como pones n8n en marcha de nuevo.

1. Aprovisionar un nuevo VPS e instalar Docker

Configura un VPS con Docker y Docker Compose. Sigue nuestra guía de instalación de n8n con Docker Compose hasta el paso de instalación de Docker, luego vuelve aquí.

2. Crear el usuario deploy y el directorio del proyecto

adduser --disabled-password deploy
mkdir -p /home/deploy/n8n /home/deploy/n8n-backups
chown deploy:deploy /home/deploy/n8n /home/deploy/n8n-backups

3. Descargar tus backups

Desde tu almacenamiento remoto:

su - deploy
rclone copy n8n-backup:your-bucket-name/n8n/daily /home/deploy/n8n-backups/daily --progress

O desde otro servidor vía scp:

scp user@old-server:/home/deploy/n8n-backups/daily/* /home/deploy/n8n-backups/daily/

4. Restaurar archivos de configuración

cp /home/deploy/n8n-backups/daily/env-*.bak /home/deploy/n8n/.env
cp /home/deploy/n8n-backups/daily/docker-compose-*.yml.bak /home/deploy/n8n/docker-compose.yml
chmod 600 /home/deploy/n8n/.env

Verifica que la clave de cifrado está presente:

grep N8N_ENCRYPTION_KEY /home/deploy/n8n/.env

Este comando debe devolver una línea con tu clave. Si está vacía o no aparece, busca la clave en tu gestor de contraseñas y añádela manualmente. Sin esta clave, tus credenciales están perdidas.

5. Iniciar solo PostgreSQL

cd /home/deploy/n8n
docker compose up -d postgres

Espera a que PostgreSQL se inicialice:

docker compose logs -f postgres

Busca database system is ready to accept connections.

6. Restaurar la base de datos

docker cp /home/deploy/n8n-backups/daily/n8n-db-*.dump n8n-postgres:/tmp/n8n.dump
docker exec n8n-postgres pg_restore -U n8n -d n8n --clean --if-exists /tmp/n8n.dump

Qué hace este comando: Copia el archivo dump dentro del contenedor, luego pg_restore lo carga. --clean elimina los objetos existentes antes de restaurar. --if-exists previene errores si los objetos aún no existen.

Puede que veas algunos avisos sobre objetos que no existen. Es normal en una base de datos nueva. Los errores sobre datos o restricciones no son normales.

7. Restaurar el volumen Docker

Docker Compose ya creó el volumen n8n_n8n_data cuando iniciaste PostgreSQL en el paso anterior. Restaura en él:

docker run --rm \
  -v n8n_n8n_data:/target \
  -v /home/deploy/n8n-backups/daily:/backup:ro \
  alpine sh -c "tar xzf /backup/n8n-data-*.tar.gz -C /target"

8. Iniciar el stack completo

docker compose up -d

9. Verificar la restauración

docker compose ps

Todos los contenedores deberían mostrar el estado running.

Revisa los logs de n8n:

docker compose logs -f n8n

Busca Editor is now accessible via: http://localhost:5678. Sin errores de clave de cifrado.

Abre la interfaz web de n8n y verifica:

  1. Los workflows existen y coinciden con lo que tenías antes.
  2. Las credenciales funcionan. Abre cualquier credencial y confirma que muestra los valores almacenados (claves API, contraseñas). Si ves campos vacíos o errores de descifrado, tu clave de cifrado es incorrecta.
  3. Ejecuta un workflow de prueba. Lanza un workflow simple para confirmar que la conexión a la base de datos y el motor de ejecución funcionan.

Prueba desde fuera del servidor:

curl -s https://your-n8n-domain.com/healthz

Una respuesta 200 confirma que n8n es accesible y está funcionando.

¿Cómo actualizar n8n de forma segura con Docker Compose?

Actualizar n8n sigue cuatro pasos: respaldar, revisar las notas de la versión, descargar la nueva imagen y verificar. Nunca te saltes el paso de backup.

1. Ejecutar un backup

/home/deploy/n8n/backup-n8n.sh

Es obligatorio. Si la actualización rompe algo, necesitas un punto de restauración.

2. Revisar las notas de la versión por breaking changes

Antes de descargar la nueva versión, lee las notas de la versión de n8n. Busca:

  • Migraciones de base de datos (se ejecutan automáticamente al inicio pero pueden tardar)
  • Nodos obsoletos que tus workflows usan
  • Variables de entorno cambiadas
  • Requisitos mínimos de versión de PostgreSQL

3. Anotar tu versión actual

docker compose exec n8n n8n --version

Apúntala. La necesitas para el rollback.

4. Descargar y reiniciar

Si tu docker-compose.yml usa el tag n8nio/n8n:latest o n8nio/n8n:stable:

cd /home/deploy/n8n
docker compose pull
docker compose down
docker compose up -d

Si fijas una versión específica (recomendado para producción), edita docker-compose.yml primero:

services:
  n8n:
    image: n8nio/n8n:2.12.3  # Change to the target version

Luego:

docker compose up -d

5. Verificar la actualización

docker compose exec n8n n8n --version

Confirma que la versión coincide con lo esperado.

Revisa los logs por errores de migración:

docker compose logs --tail 50 n8n

Busca Migrations completed y Editor is now accessible via: http://localhost:5678.

Prueba el endpoint de salud de la API:

curl -s https://your-n8n-domain.com/healthz

Ejecuta un workflow de prueba a través de la interfaz para confirmar que la ejecución funciona.

¿Cómo hacer rollback tras una actualización fallida de n8n?

Si la actualización rompe workflows o la interfaz no es accesible, vuelve a la versión anterior.

1. Detener la instancia rota

cd /home/deploy/n8n
docker compose down

2. Establecer el tag de imagen anterior

Edita docker-compose.yml y cambia la imagen a tu versión anterior:

services:
  n8n:
    image: n8nio/n8n:2.11.2  # Your previous working version

3. Restaurar la base de datos si se ejecutaron migraciones

Si n8n ejecutó migraciones de base de datos durante la actualización fallida, el esquema puede haber cambiado. Restaura desde tu backup pre-actualización:

docker compose up -d postgres
docker cp /home/deploy/n8n-backups/daily/n8n-db-*.dump n8n-postgres:/tmp/n8n.dump
docker exec n8n-postgres pg_restore -U n8n -d n8n --clean --if-exists /tmp/n8n.dump

4. Iniciar la versión anterior

docker compose up -d

Verifica:

docker compose exec n8n n8n --version
docker compose logs --tail 20 n8n

Por esto hacemos backup antes de cada actualización. Sin el dump pre-actualización, no puedes hacer downgrade de forma segura después de una migración.

¿Cómo migrar n8n de la versión 1.x a 2.x?

n8n 2.0 se publicó en diciembre de 2025 con breaking changes. Si todavía estás en 1.x, migra pronto. La versión 1.x recibió solo correcciones de seguridad durante tres meses tras el lanzamiento de 2.0, y esa ventana ya se cerró.

Breaking changes principales en n8n 2.0

Cambio Comportamiento 1.x Comportamiento 2.x Acción requerida
Soporte MySQL/MariaDB Soportado Eliminado por completo Migrar a PostgreSQL antes de actualizar
Task runners Opcional Activado por defecto, imagen Docker separada Usar imagen n8nio/runners para modo externo
Variables de entorno en Code node Accesibles Bloqueadas por defecto Establecer N8N_BLOCK_ENV_ACCESS_IN_NODE=false si es necesario
Start node Funcional Eliminado Reemplazar con nodos trigger específicos
Save vs. Publish Save = deploy Save y Publish son acciones separadas Actualizar workflows del equipo
Python Code node Basado en Pyodide Python nativo vía task runners Usar task runners en modo externo
Nodos ExecuteCommand y LocalFileTrigger Activados Desactivados por defecto Activar explícitamente si es necesario
Opción CLI --tunnel Disponible Eliminada Usar un reverse proxy en su lugar
N8N_CONFIG_FILES Soportado Eliminado Usar variables de entorno directamente

Paso 1: Ejecutar el informe de migración

La herramienta de informe de migración está disponible desde n8n 1.121.0. Identifica problemas a nivel de workflow e instancia antes de actualizar.

En la interfaz de n8n, ve a Settings > Migration Report. Solo es visible para administradores globales.

El informe tiene dos pestañas:

  • Workflow Issues: Lista workflows que usan nodos obsoletos, funcionalidades eliminadas o comportamientos cambiados.
  • Instance Issues: Señala variables de entorno y configuración que necesitan actualización.

Corrige cada problema identificado por el informe antes de continuar.

Paso 2: Actualizar primero a la última versión 1.x

Antes de saltar a 2.x, actualiza a la última versión 1.x. Esto asegura que todas las migraciones de base de datos intermedias se ejecuten:

docker compose pull  # With image set to n8nio/n8n:1-latest or latest 1.x tag
docker compose down && docker compose up -d

Paso 3: Respaldar todo

/home/deploy/n8n/backup-n8n.sh

Este es tu punto de rollback. Si 2.x rompe tu configuración, puedes restaurar este backup y quedarte en 1.x.

Paso 4: Actualizar a 2.x

Edita docker-compose.yml:

services:
  n8n:
    image: n8nio/n8n:stable  # Or a specific 2.x version like 2.12.3

docker compose pull
docker compose down
docker compose up -d

Paso 5: Verificar la migración

docker compose logs --tail 100 n8n

Busca migraciones completadas y ausencia de errores.

Prueba los workflows que el informe de migración señaló. Abre credenciales para confirmar que el descifrado funciona. Ejecuta algunos workflows de principio a fin.

Si algo está roto, haz rollback usando el procedimiento de la sección anterior con tu backup 1.x y el tag de imagen 1.x.

Resolución de problemas

pg_dump: error: connection to server failed El contenedor PostgreSQL no está en ejecución. Inícialo con docker compose up -d postgres y espera a que esté listo antes de ejecutar backups.

Las credenciales aparecen vacías después de restaurar Tu N8N_ENCRYPTION_KEY no coincide con la que se usó cuando se guardaron las credenciales. Revisa tu archivo .env. Compárala con la clave en tu gestor de contraseñas.

docker exec falla con "no such container" Los nombres de contenedores dependen del nombre de tu directorio de proyecto y del archivo compose. Ejecuta docker ps para encontrar el nombre real del contenedor. Ajusta la variable DB_CONTAINER en el script de backup.

El script de backup se ejecuta pero el healthcheck nunca hace ping Verifica que HEALTHCHECK_URL está definido en el script. Prueba la URL manualmente: curl -fsS "your-healthcheck-url". Las reglas de firewall podrían estar bloqueando HTTPS saliente.

n8n no inicia después de actualizar con error de migración Revisa los logs con docker compose logs n8n. Si el error menciona una migración específica, busca ese error en el foro comunitario de n8n. Haz rollback si es necesario.

rclone sync falla con error de autenticación Ejecuta rclone config reconnect n8n-backup: para renovar credenciales. Verifica que tu clave de acceso y secreto sean correctos.

Dónde están los logs:

# n8n application logs
docker compose logs -f n8n

# PostgreSQL logs
docker compose logs -f postgres

# Backup script log
tail -f /home/deploy/n8n-backups/backup.log

# Cron execution log
grep CRON /var/log/syslog | tail -20

Copyright 2026 Virtua.Cloud. Todos los derechos reservados. Este contenido es una obra original del equipo de Virtua.Cloud. La reproducción, republicación o redistribución sin permiso escrito está prohibida.

¿Listo para probarlo?

Despliega tu propio servidor en segundos. Linux, Windows o FreeBSD.

Ver planes VPS