标准流程是只搬数据、不搬状态，确保解密一致、路径可映射、权限不丢；备份对象为数据卷、配置与环境变量、加密密钥三类；按场景用docker cp、tar或pg_dump备份；恢复后须校验凭据、webhook和执行历史；收尾需清理敏感信息、更新文档并定时脚本化。
标准流程不是“停容器→打包→重启”这么简单，关键在只搬数据、不搬状态，确保新旧环境解密一致、路径可映射、文件不丢权限。
明确备份对象：分清“数据卷”“配置”和“加密密钥”
容器内真正要保留的是三类东西：
-
数据卷（Volume）：存放数据库、日志、上传文件等持久化内容。用
docker volume ls查看，确认哪些卷实际被应用使用（比如n8n_data或postgres_data）。 -
配置与环境变量：包括
.env、docker-compose.yml中的N8N_ENCRYPTION_KEY、DB_TYPE、时区、Webhook 地址等——这些决定服务行为，漏一项就可能启动失败或凭据失效。 -
加密密钥（尤其 N8N/Keycloak 类服务）：如
N8N_ENCRYPTION_KEY必须完全一致，否则所有 credentials 解不开，工作流全报错。它不存于数据卷，而来自环境变量或配置文件。
执行备份：按场景选合适方式
根据数据规模和一致性要求选择方法：
-
小量配置/代码类目录（如 Nginx 配置、N8N 的
.n8n目录）：直接用docker cp拉取：docker cp n8n-container:/home/node/.n8n ./backup-n8n-$(date +%F) -
大体积数据卷（如 PostgreSQL、MongoDB 数据）：用临时容器 +
tar打包，保证路径和权限完整：docker run --rm -v n8n_data:/volume -v $(pwd):/backup alpine tar -czf /backup/n8n_data-$(date +%F).tar.gz -C /volume . -
数据库内容级备份（强一致性要求）：进容器调用原生工具，例如：
docker exec postgres-container pg_dump -U n8n n8n_db > backup.sql，再docker cp导出。
恢复与验证：先还原基础，再校验功能
恢复不是“把文件拷回去就完事”，必须闭环验证：
- 先在新环境重建相同名称的数据卷或挂载目录，确保权限为
node:node（N8N）或postgres:postgres（PostgreSQL）等对应用户； - 用
docker cp或tar -xzf恢复文件后，检查属主和读写权限（如chown -R node:node .n8n）； - 启动容器前，确认
N8N_ENCRYPTION_KEY已写入新.env，且值与备份时完全一致（建议用sha256sum校验）； - 启动后重点验证三项：
– 凭据是否能正常加载（点开任一节点看认证字段是否显示“Connected”）
– Webhook 是否能收到请求（用 curl 测试）
– 最近一次执行历史是否可见（证明 SQLite/Postgres 数据已生效）。
收尾动作：清理+记录+定时化
一次演练结束不等于完成，还要做三件事：
- 删除临时备份容器、压缩包中敏感字段（如数据库密码明文）、旧备份（保留最近 3 个版本即可）；
- 更新迁移文档，注明本次使用的镜像版本、
DB_TYPE模式、加密密钥长度、是否启用队列模式； - 把核心备份命令写成脚本，加入
cron，例如每天凌晨 2 点自动备份数据卷并打时间戳，避免靠人想起来才做。
