Copias de seguridad de n8n: que existan no basta

Durante casi cinco meses tuvimos dos sistemas de copia de seguridad funcionando en un servidor de n8n. Los dos corrían todas las noches. Los dos terminaban sin error. Los dos eran inútiles.

Uno hacía un volcado (dump, una exportación completa) de la base de datos PostgreSQL donde n8n guarda los workflows, las credenciales cifradas y el historial de ejecuciones. El problema es que apuntaba a una base de datos que ya no era la que usaba n8n. Meses atrás habíamos migrado el contenedor y cambiado el nombre del servicio. El cron de backup seguía apuntando al nombre viejo, que seguía existiendo, vacío, sin ningún dato nuevo desde el día de la migración. Cada noche hacíamos una copia perfecta de una base de datos muerta.

El otro sistema exportaba los workflows en formato JSON usando la línea de comandos de n8n y subía el fichero a un almacenamiento externo. También corría sin errores. También llevaba meses fallando: por un problema de permisos, el comando no llegaba a ejecutar la exportación real y generaba un JSON de error en su lugar. El fichero resultante pesaba siempre 415 bytes. Da igual cuántos workflows tuviéramos, cuántos cambios hubiéramos hecho: 415 bytes, noche tras noche.

Lo descubrimos porque tuvimos que restaurar de verdad. No fue un ejercicio de auditoría ni una revisión rutinaria. Fue un incidente real en el que necesitábamos los datos y no estaban.

Por qué pasó y por qué nadie se dio cuenta

Ninguno de los dos scripts fallaba en el sentido técnico de la palabra. Terminaban con código de salida cero, que es lo que la mayoría de sistemas de monitorización interpreta como “todo bien”. El cron corría, el fichero se generaba, se subía donde tenía que subirse. Todas las señales que normalmente se vigilan decían que funcionaba.

Lo que nadie miraba era el contenido. Ni el tamaño del fichero, ni si cambiaba de un día para otro, ni si al abrirlo aparecían workflows reales o un mensaje de error disfrazado de JSON.

Esto tiene mucho que ver con algo que ya contamos al hablar de qué hacer cuando un workflow de n8n falla de madrugada: los fallos silenciosos son los peligrosos, no los que gritan. Un backup que falla y avisa es un problema resuelto en cinco minutos. Un backup que falla en silencio durante meses es una bomba con temporizador.

Qué hay que respaldar realmente en n8n

Antes de hablar de verificación, conviene tener claro qué piezas hacen falta para poder reconstruir una instalación de n8n desde cero. No es solo “los workflows”.

• La base de datos (PostgreSQL o SQLite, según cómo esté instalado): contiene los workflows, el historial de ejecuciones y las credenciales, aunque estas últimas van cifradas.
• La clave de cifrado (encryption key): es la que convierte las credenciales guardadas en algo utilizable. Sin ella, tener la base de datos no sirve de nada: las credenciales son ilegibles. Sobre esto ya hablamos al explicar cómo guardar credenciales en n8n sin dejarlas en texto plano, y es el detalle que más gente olvida respaldar.
• Los ficheros de configuración: variables de entorno, configuración de webhooks, certificados si los hay.
• Los workflows exportados en JSON: útil como copia adicional, legible y fácil de revisar a simple vista, pero no sustituye a la base de datos completa porque no incluye ejecuciones ni credenciales.

Un backup que solo guarda los JSON de los workflows es mejor que nada, pero es una copia parcial. Si el servidor se cae, recuperarás los workflows pero tendrás que volver a configurar cada credencial una por una.

Cómo comprobar que una copia sirve de verdad

Que un backup “exista” significa que hay un fichero en algún sitio. Que un backup “sirva” significa que, si todo se destruye esta noche, mañana puedes tener el sistema funcionando otra vez con esos datos. Son dos cosas distintas y la confusión entre ambas es la causa de casi todos los desastres de este tipo.

Pasos concretos, en orden:

1. Mira el tamaño del fichero, no solo su existencia. Un backup de una base de datos con actividad real no debería pesar lo mismo semana tras semana. Si el tamaño está congelado, algo no se está capturando.

2. Compara el contenido con lo que hay en producción. Abre el JSON exportado o restaura el dump en una base de datos de prueba y cuenta los workflows. Si en producción hay veinte workflows activos y el backup solo tiene doce, ya sabes que algo se queda fuera.

3. Haz una restauración real, no una simulación mental. Levanta una instancia de n8n en un entorno separado —un contenedor local, por ejemplo— y restaura ahí el backup. Si arranca y los workflows aparecen tal cual estaban, la copia sirve. Si algo falla al restaurar, mejor descubrirlo un martes tranquilo que la noche que de verdad lo necesitas.

4. Comprueba la fecha de modificación real de los datos, no solo la fecha en que se generó el fichero. Un backup puede “generarse hoy” a partir de datos de hace meses, como nos pasó a nosotros. La fecha del fichero engaña; el contenido no miente.

5. Pon una alerta sobre el tamaño mínimo esperado. Si el backup de la base de datos baja de un umbral razonable, o el JSON de workflows pesa menos de unos pocos kilobytes teniendo docenas de workflows, algo va mal. Un fichero de 415 bytes debería haber disparado una alarma el primer día, no descubrirse cinco meses después.

6. Guarda la clave de cifrado en un sitio distinto al de la base de datos. Si ambas cosas están en el mismo servidor y ese servidor desaparece, da igual cuántas copias de la base de datos tengas: sin la clave, las credenciales son inservibles.

Cuándo no merece la pena complicarse tanto

Si tu instalación de n8n solo mueve un puñado de workflows internos, sin credenciales críticas ni datos de clientes, montar un sistema de verificación elaborado puede ser desproporcionado. En ese caso, una exportación manual de los workflows cada cierto tiempo, guardada en dos sitios distintos, es suficiente.

El esfuerzo de verificación real —restauraciones de prueba, alertas de tamaño, comprobación de contenido— tiene sentido cuando n8n mueve procesos que, si desaparecieran, pararían algo del negocio: facturación, atención a clientes, integraciones con sistemas de pago. Ahí sí compensa dedicar una tarde a montar la verificación una vez, en lugar de descubrir el problema en el peor momento posible.

Lo que nos llevamos de esto

Un backup que nadie ha restaurado nunca no es un backup: es una hipótesis. La única forma de saber si sirve es intentarlo, aunque sea en un entorno de pruebas y aunque parezca perder el tiempo un día cualquiera sin incidentes.

Revisa hoy, sin esperar a necesitarlo: abre el último fichero de backup que se generó anoche. Mira su tamaño, ábrelo, comprueba que dentro hay lo que esperas encontrar. Si no lo has hecho nunca, es muy probable que tengas tu propia versión de los 415 bytes esperando a que la descubras en el peor momento.

Si prefieres no tener que acordarte de esto, la comprobación periódica va incluida cuando llevamos nosotros la automatización de procesos: el backup se restaura de verdad cada cierto tiempo, no se supone.