Dify升级与备份迁移安全操作完全指南

你需要在不停服的前提下？不，必须停服。停服务后立即执行三重备份，缺一不可——数据库（pg_dump）、volumes目录（tar打包）和配置文件（.env与docker-compose.yml）。否则知识库文件、聊天记录、工作流配置以及权限设置将全部蒸发，到时候哭都来不及。

话不多说，直接进入正题：如何在不丢失知识库文件、聊天记录、工作流配置的前提下顺利完成Dify版本升级，同时确保新版本能无缝继承旧版所有数据和权限设置。

升级前必须做的三重备份

停掉Dify服务后立刻做下面三件事，少一件都不行。数据库没备份？升级后所有应用、用户、知识库索引全部消失。上传文件没备份？PDF、Word等原始文件永久消失。配置文件没备份？端口、密钥、模型地址全部变成废纸。

第一步：停止全部容器，进入Dify部署目录（比如 /opt/dify/docker），运行：
docker compose down

第二步：备份PostgreSQL数据库。这里推荐单库备份，体积小、恢复快：
docker compose exec db pg_dump -U postgres dify > /backup/dify_db_$(date +%Y%m%d_%H%M%S).sql
【必须确认输出无报错，且生成了一个非空的.sql文件，否则备份等于白做】

第三步：打包volumes目录，这里面存放着知识库原始文件、上传附件、日志等关键数据：
tar -czvf /backup/dify_volumes_$(date +%Y%m%d_%H%M%S).tar.gz ./volumes

第四步：复制.env和docker-compose.yml到备份目录：
cp .env docker-compose.yml /backup/

保留数据的两种升级路径

根据你当前的部署方式选择对应方法，别混用。

方法一：Git拉取升级（推荐用于源码部署用户）
进入Dify项目根目录，执行：
git fetch origin && git checkout -b v1.13.2 origin/v1.13.2
在覆盖原docker目录下的配置之前，先拿diffchecker对比新旧docker-compose.yml的差异——只合并你手动修改过的字段（比如EXPOSURE_PLUGIN_DEBUGGING_PORT），其余保持新版本默认值，别自作主张。

方法二：宝塔面板内升级（适用于使用BT面板安装的用户）
在面板的「软件商店」中搜索Dify，点击「安装」新版本。注意修改暴露端口避免冲突（比如旧版用3000，新版就设成3001）；安装完成后立刻停止新容器，再进行下一步数据迁移。

关键：volumes数据卷迁移操作

这一步决定了你是否真的能保住知识库和上传文件。新版本容器必须完全停止，否则Linux会锁死volumes目录，复制必然失败。

① 进入新版本Dify的docker目录（比如 /www/dk_project/dk_app/dify_v1132/dify_v1132_XYZ/）
② 删除空的volumes目录：
rm -rf volumes
③ 解压并还原旧版volumes：
tar -xzvf /backup/dify_volumes_20260606_*.tar.gz
④ 修复权限——这一步不做，API服务启动就会报错：
chown -R 1001:1001 volumes
【注意：1001是Dify最新镜像的固定UID，不是root也不是你当前用户的ID】

启动与验证

在新版本docker目录下执行：
docker compose up -d

等待30秒后查看日志：
docker compose logs -f api | grep "Uvicorn running"
看到这个提示，代表API服务已经准备就绪。此时打开浏览器访问新端口，登录后逐一检查：知识库列表是否完整？任意一个PDF是否能正常预览？工作流节点参数是否跟升级前一模一样？全部通过，才算升级成功。

你是一名 AI 行业编辑，请围绕下面这条热点输出一份资讯解读：
热点：Dify升级与备份迁移安全操作完全指南要求：
1. 先用一句话解释这条热点在讲什么
2. 再总结它为什么重要
3. 说明会影响哪些 AI 产品或内容方向
4. 最后给出 3 个适合资讯站使用的标题