Docker 应用备份与迁移：配置、数据目录和恢复顺序

迁移容器之前，先找数据在哪里

Compose 文件说明容器怎样启动，数据通常在绑定目录或命名卷。先打开 compose.yaml 查看 volumes，再用 docker inspect 对照实际挂载；镜像可以重新下载，数据库和上传文件需要自己保存。

sudo docker compose ps
sudo docker inspect 容器名 --format "{{json .Mounts}}"

小型 SQLite 应用可以停机后打包

以 /srv/memos/data 保存数据的单实例应用为例，先停止应用，再把数据和配置打包到项目目录以外。下面的目录必须换成自己的实际位置，确认 tar 包生成后再启动服务。

cd /srv/memos
sudo docker compose stop
sudo tar -czf /srv/memos-backup-$(date +%F).tar.gz compose.yaml data
sudo docker compose start

打包结束后把备份复制到另一台机器或外部存储。打包数据库正在写入的文件可能得到不一致的副本；MySQL、PostgreSQL 使用它们各自的逻辑导出或一致性备份方式。

有数据库的应用分别保存什么

保存数据库导出、上传目录、Compose 文件与 .env。n8n 等应用还依赖加密密钥，只有数据库却缺少原密钥，可能无法恢复已保存的凭据。备份文件按时间放在同一组，记录软件与数据库版本。

先在新 VPS 恢复，再切换域名

新机器安装 Docker，复制配置与数据，保持正确的目录权限。数据库按对应版本恢复后启动应用，检查登录、文章、附件和后台任务。确认新实例能完整工作，再把域名指向新服务器。

需要短暂停写的应用，在最终迁移时停下旧实例并做最后一份一致数据；不要让两个实例同时向各自独立数据库写入后再尝试合并。

恢复完成后保留回退资料

保留旧机器数据与迁移前备份，直到新实例完成必要检查。清理容器不需要删除数据卷；不要用 compose down -v 代替普通停止操作。下一次升级沿用这套备份与恢复记录。

命名卷也要保存

Compose 项目不一定把数据放在当前目录。先用 docker compose config 查看 volumes，再用 docker volume inspect 查看实际卷；项目名前缀也会影响卷名。

数据库卷优先使用数据库工具导出。一般文件卷可在停止写入后挂到临时工具容器中打包，保存时保留目录、权限和所需配置；不要只复制 compose.yml。

恢复后怎样判断成功

在目标机器启动对应版本服务后，分别检查登录、历史数据、附件和新增写入。数据库记录存在但图片打不开，通常还需检查文件卷、目录和挂载路径。

通知、Webhook、定时任务与外部服务白名单也检查一次。应用首页能打开，只证明入口已经工作，不能代表全部数据恢复。

保留原数据再升级版本

先用原版本恢复，再按软件支持的升级路径更新。PostgreSQL 等数据库大版本不能直接复用旧数据目录，使用逻辑导出恢复或对应升级工具。

新环境验证完成前保留旧机和备份。docker compose down -v 会删除项目卷，不用于普通重启或镜像更新。

数据库和上传文件，要来自同一个恢复点

应用正在上传文件时，数据库和目录分别复制可能产生不同时间点的副本。迁移前安排停写窗口：停止接收新任务、上传和 Webhook，等待正在执行的任务结束，再保存数据库与文件。保留数据库服务运行以执行逻辑导出，不能先停数据库再运行 pg_dump。

PostgreSQL 的 pg_dump 可以取得数据库一致快照，但它不能同时冻结应用文件目录。下面假定 Compose 服务名为 db，替换数据库账号与库名，并在停写后执行；dump 文件位于宿主机当前目录。备份目录应仅允许维护账号读取。

umask 077
docker compose exec -T db pg_dump -U DB_USER -d DB_NAME -Fc > database.dump
test -s database.dump

命令成功并且文件非空仍需恢复验证。数据库版本、应用版本、Compose、.env、密钥和上传目录写入同一份备份记录。MySQL 或外部数据库使用对应官方一致性备份方法，不把 pg_dump 命令照搬过去。

异机恢复后，用真实业务动作检查

在隔离机器上先恢复与备份匹配的数据库及文件，再使用原应用版本启动。试运行关闭定时任务、通知和外部写入，避免恢复副本重复发邮件或触发业务。用 --resolve 或受控临时域名检查 HTTPS，公网 DNS 先不切换。

验证包括登录、读取旧记录、下载附件、创建一条临时记录及后台任务处理。对文件副本抽查校验和；检查数据库恢复命令的退出状态与日志，再核对应用内数量和关键记录。容器 Up 或数据库能连接，只是恢复检查的一部分。

切换期间只有一份业务数据继续写入

预演通过后，旧实例停写，做最终备份并恢复到目标实例，再切换域名或代理入口。DNS 缓存可能让部分请求仍到旧机器，旧入口应维持停写或转发到新入口，避免两个数据库各自产生新记录。

切换前记录旧解析、代理配置、数据快照和版本。新实例尚未接收业务写入时，可恢复旧入口；新实例已经有新数据时，先再次停写并保存新数据，再制定回迁步骤。不能只把 DNS 改回去就宣布回退完成，否则会丢失切换后的记录。