Fazer backup do n8n exige salvar duas coisas separadas: o banco de dados (onde ficam fluxos, execuções e credenciais criptografadas) e a chave de criptografia (sem a qual as credenciais salvas viram dado ilegível). Esquecer a segunda é o erro mais caro — o banco pode estar intacto e ainda assim inútil.
Adicione ao Google NotíciasNeste artigo
Backup do banco: SQLite
Se a instância usa o banco padrão SQLite, o cuidado principal é nunca copiar o arquivo com o n8n rodando — o risco de corrupção é real.
# Opção segura: parar antes de copiar
docker compose stop n8n
cp /caminho/.n8n/database.sqlite /backup/database-$(date +%Y%m%d).sqlite
docker compose start n8n
# Alternativa sem parar: comando de backup do próprio SQLite
sqlite3 /caminho/.n8n/database.sqlite ".backup /backup/n8n-$(date +%Y%m%d).sqlite"Backup do banco: PostgreSQL (recomendado para produção)
O Postgres aceita backup com o serviço rodando, sem risco de corrupção — mais uma razão para preferir Postgres em produção:
docker compose exec postgres pg_dump -U n8n -d n8n > backup_$(date +%F).sqlA chave de criptografia, separadamente
Guarde o N8N_ENCRYPTION_KEY em local seguro, separado do backup do banco. Sem essa chave exata, todas as credenciais salvas no banco restaurado ficam inutilizáveis — você teria fluxos completos, mas precisaria recadastrar cada credencial do zero.
Exportando fluxos individualmente
Além do backup do banco inteiro, vale exportar fluxos importantes como arquivo JSON separado, pela própria interface ou por linha de comando:
# Para versões mais recentes do n8n
n8n export:entities --outputDir=/backup/exportEssa exportação funciona como uma segunda camada de segurança — mesmo que o backup do banco falhe, os fluagens exportados individualmente continuam recuperáveis.
Uma estratégia completa, em três camadas
Banco de dados — backup regular, automatizado, com rotação de versões antigas.
Chave de criptografia — guardada separadamente, com acesso restrito.
Exportação de fluxos — periódica, como camada extra além do banco completo.
Teste a restauração pelo menos uma vez, num ambiente separado. Backup que nunca foi restaurado com sucesso não é garantia de nada — só descobre-se que algo está errado no pior momento possível, quando já se precisa dele de verdade.
Backup do banco (Postgres a quente, SQLite parado), chave de criptografia guardada à parte, e exportação de fluxos como camada extra. Teste a restauração antes de precisar dela de verdade.
Perguntas frequentes
Como fazer backup do n8n?
Fazendo backup do banco de dados — Postgres aceita backup com o serviço rodando, SQLite exige parar o n8n antes — e guardando a chave de criptografia separadamente, sem a qual as credenciais salvas ficam inutilizáveis.
Por que a chave de criptografia precisa de backup separado?
Porque é ela que decifra as credenciais salvas no banco. Sem a chave exata usada originalmente, um banco restaurado tem os fluxos intactos, mas as credenciais tornam-se ilegíveis, exigindo recadastro completo.
Dá para fazer backup do SQLite com o n8n rodando?
Não é seguro copiar o arquivo diretamente com o serviço ativo — risco de corrupção. A alternativa é usar o comando de backup nativo do SQLite, que funciona de forma segura mesmo com o banco em uso, ou parar o n8n antes de copiar.
Este tutorial faz parte do guia Curso de n8n do zero ao avançado: o guia completo em português. Veja também: Node, trigger e workflow: o vocabulário do n8n em 10 minutos · A estrutura de dados do n8n: por que tudo é um array com json · Item linking no n8n: como ele decide qual item vai pra saída · Execuções passo a passo: como achar onde o fluxo do n8n quebrou · A Canvas UI do n8n 2.0: o que mudou e como se orientar · n8n Cloud ou self-hosted: a decisão que define seu custo e sua liberdade
