Cómo recuperar automatizaciones n8n después de una caída del servidor

Publicado el 2026-11-14 por frfrand

Plan de recuperación de n8n con persistencia, PostgreSQL, volúmenes, cola de ejecuciones, reintentos y prevención de duplicados.

# Cómo recuperar automatizaciones n8n después de una caída del servidor

Un reinicio de n8n no debería obligarte a reconstruir flujos de trabajo. Pero que el editor vuelva a abrir no prueba que los eventos pendientes hayan sobrevivido. Para recuperar un servicio de automatización hay que proteger configuración, claves, base de datos, cola y efectos de negocio. ## Qué datos son imprescindibles Documenta la versión instalada, configuración de despliegue, variables de entorno, clave de cifrado de credenciales y ubicación de la base de datos. Si se pierde la clave de cifrado, restaurar una base con credenciales cifradas puede no permitir utilizarlas. Guarda secretos en un gestor seguro, separado de las copias de seguridad y con acceso controlado. Identifica también los datos binarios y archivos almacenados por flujos de trabajo, según el modo de almacenamiento configurado. Un volumen efímero puede borrar información necesaria aunque PostgreSQL siga intacto. ## Preparar copias consistentes Programa copias de base de datos y archivos persistentes, protege la configuración y realiza ensayos de restauración en un entorno aislado. Comprueba que la restauración produce flujos de trabajo completos y conexiones operativas. Define cuánto dato puedes perder (RPO) y cuánto tardarás en recuperar (RTO). No copies sin más archivos de una base activa esperando consistencia; emplea los mecanismos de copia de seguridad apropiados. ## Reiniciar de manera controlada Primero confirma si el problema es el proxy, la aplicación, la base de datos, Redis o un servicio externo. Consulta registros de systemd o contenedores, espacio en disco, OOM y conectividad. Comprueba que los servicios dependientes están sanos antes de arrancar múltiples workers. Si el proceso vuelve a caer, evita ciclos infinitos sin investigación. Las ejecuciones en curso al momento de la caída pueden tener estados distintos según versión y configuración. No presupongas que todas se reanudan desde el último nodo. ## Evitar perder eventos o duplicarlos En muchos sistemas, el riesgo mayor no es perder un flujo de trabajo sino ejecutar dos veces una acción: enviar dos correos electrónicos, crear dos oportunidades o cobrar dos veces. Introduce claves de idempotencia basadas en un identificador de evento y registra el estado antes de producir el efecto externo. Los reintentos deben comprobar si la acción ya se completó. Para webhooks, distingue recepción aceptada, procesamiento iniciado y confirmación de efecto. Conserva un registro auditable que permita reconciliar eventos contra el sistema de origen. ## Checklist tras la recuperación - Editor y flujos de trabajo activos visibles. - Credenciales descifrables y conexiones comprobadas. - Triggers, webhooks y cron reactivados de forma intencional. - Cola y ejecuciones fallidas revisadas sin reenvíos indiscriminados. - Correo electrónico, CRM y servicios externos comprobados con eventos de prueba. - Alertas y copias verificadas. ## Preguntas frecuentes ### ¿Basta con hacer copia de seguridad del volumen Docker? No necesariamente: depende de dónde estén PostgreSQL, secretos y binarios. ### ¿Se reanudan las ejecuciones siempre? No debes asumirlo; prueba el comportamiento de tu despliegue concreto. ### ¿Se puede evitar al cien por cien una repetición? Diseña los efectos de negocio para tolerar reentregas; el «exactly once» extremo a extremo no debe darse por supuesto. ## Recursos Revisa webhooks seguros con n8n y copias de seguridad PostgreSQL. ArduMaker puede proporcionar infraestructura para desplegar y vigilar n8n con un plan de recuperación definido.