1. 为什么备份与迁移是 Dify 落地的必修课把 Dify 跑起来不算本事能把它的数据安全地搬走、在另一个环境里原样跑起来才算真正把这块技术吃透了。我见过太多团队在测试环境里玩得风生水起一到要换服务器、要做容灾、要给客户做私有化交付的时候直接傻眼——工作流丢了、知识库对不上、对话记录全没了最后只能从头再搭一遍。这种痛踩过一次就再也不想踩第二次。Dify 这个平台本质上是一个“有状态”的应用。它不像一个纯前端页面拷个文件夹就能跑。它背后挂着关系型数据库、缓存、向量库、文件存储这一整套东西任何一个环节没搬对迁移过去就是一堆报错。所以这篇文章我想聊的就是怎么把 Dify 从一台机器完整地搬到另一台机器怎么在单机环境下做好容灾以及怎么在开发、测试、生产这些不同环境之间做无缝迁移。适合谁看如果你正在用 Docker Compose 部署 Dify或者准备把它交付到客户的内网环境又或者你只是单纯担心哪天服务器挂了数据找不回来那这篇内容应该能帮到你。我会把整个思路拆开讲包括为什么要这么备份、每一步在干什么、参数怎么定、坑在哪里。不堆概念只讲能直接抄作业的东西。2. 先搞清楚 Dify 到底存了哪些数据2.1 四类核心数据一个都不能少很多人做备份的时候只盯着数据库觉得把 PostgreSQL 导出来就万事大吉了。实测下来这种想法会让你在恢复的时候哭出来。Dify 的数据至少分成四块每一块的备份方式和恢复优先级都不一样。第一块是关系型数据库默认用的是 PostgreSQL。这里面存的是最核心的元数据应用配置、工作流编排的节点和连线、提示词、模型供应商的密钥、用户账号、租户信息、对话会话和消息记录。可以说数据库就是 Dify 的大脑丢了它等于从零开始。第二块是向量数据库常见的是 Weaviate 或者 Qdrant。知识库里的文档被切分、向量化之后就存在这里。它和关系库是配合关系——关系库里存的是知识库的“目录信息”向量库里存的是实际的向量和分片内容。两者必须配套单独恢复一个没有意义。第三块是文件存储默认落在本地的一个 volumes 目录里。用户上传的原始文档、生成的图片、导出的文件都在这里。这块最容易被忽略因为它在容器里看起来不起眼但一旦丢失知识库里的文档就变成了“有索引没原文”的空壳。第四块是配置文件和环境变量也就是.env文件和docker-compose.yaml。这里面有数据库密码、密钥、存储路径、各种开关。迁移到新环境时如果这些配置对不上服务根本起不来。我习惯把这两个文件单独拎出来做版本管理改一次记一次。2.2 数据之间的依赖关系理解依赖关系才能理解恢复顺序。打个比方数据库像是图书馆的借阅目录向量库像是书架上的书文件存储像是书里的具体内容。你恢复的时候如果先恢复目录再恢复书最后发现书的内容对不上那就白干了。正确的逻辑是先恢复基础设施数据库和向量库的服务本身再恢复数据内容最后校验一致性。具体来说PostgreSQL 和向量库要先能正常启动然后把各自的备份导入进去文件存储直接拷贝回对应目录最后启动 Dify 的应用容器让它自己去连接这些服务。顺序错了应用容器会因为连不上依赖而反复重启日志里全是连接超时。还有一个细节数据库里的租户 ID、应用 ID 这些主键在迁移前后必须保持一致。如果你用pg_dump导出再导入默认是保留这些 ID 的没问题。但如果你手动改过数据或者用了某些会重新生成 ID 的工具那向量库里的关联就会断掉。这一点在做跨环境迁移时尤其要注意。3. 单机容灾把备份做成自动化3.1 备份策略怎么定单机环境下最怕的就是磁盘坏了或者误删了数据。我的建议是“本地快照 异地导出”双保险。本地快照用文件系统或者云厂商的磁盘快照功能恢复快但防不了整机故障。异地导出就是把备份文件传到另一台机器或者对象存储上防的是灾难性故障。备份频率取决于你的数据变化速度。如果是内部测试用每天一次足够了。如果是生产环境对话记录一直在写那数据库最好做到每小时一次增量每天一次全量。向量库的变化相对少因为知识库不会天天重建可以跟着数据库一起做。这里有个经验值数据库全量备份的时间窗口要避开业务高峰。PostgreSQL 的pg_dump在数据量大的时候会锁表虽然 Dify 的并发一般不高但保险起见还是放在凌晨做。向量库的备份更重Weaviate 的备份接口会占用较多 IO也要错峰。3.2 用脚本把备份串起来手动备份迟早会忘所以一定要写成脚本挂到定时任务里。下面这个脚本是我自己在用的简化版思路是先把数据库导出来再把向量库和文件目录打包最后统一压缩加时间戳。#!/bin/bash # dify_backup.sh BACKUP_DIR/data/backups/dify DATE$(date %Y%m%d_%H%M%S) mkdir -p $BACKUP_DIR/$DATE # 1. 备份 PostgreSQL docker exec dify-db pg_dump -U postgres dify $BACKUP_DIR/$DATE/dify_db.sql # 2. 备份向量库数据目录以 Weaviate 为例 docker run --rm -v dify_weaviate_data:/data -v $BACKUP_DIR/$DATE:/backup alpine \ tar czf /backup/weaviate_data.tar.gz -C /data . # 3. 备份文件存储 docker run --rm -v dify_storage:/data -v $BACKUP_DIR/$DATE:/backup alpine \ tar czf /backup/storage.tar.gz -C /data . # 4. 备份配置文件 cp /path/to/dify/.env $BACKUP_DIR/$DATE/ cp /path/to/dify/docker-compose.yaml $BACKUP_DIR/$DATE/ # 5. 打包整体 cd $BACKUP_DIR tar czf dify_backup_$DATE.tar.gz $DATE rm -rf $DATE这个脚本里有几个点值得说。第一我用docker run --rm起一个临时容器来打包 volume这样不用去宿主机上找 volume 的真实路径兼容性更好。第二数据库导出用的是pg_dump而不是直接拷数据目录因为直接拷文件在数据库运行时会不一致导出的 SQL 才是逻辑一致的。第三配置文件和数据放在一起恢复的时候不会漏。提示pg_dump导出的文件是纯文本 SQL体积可能比较大。如果数据量上去了可以加-Fc参数导出成自定义格式体积小且支持并行恢复但恢复时要用pg_restore。3.3 恢复演练比备份本身更重要备份文件躺在那里你永远不知道它能不能用。我踩过的坑是备份脚本跑了大半年真到要恢复的时候发现向量库的 volume 名字写错了备份出来的是个空目录。所以每隔一段时间一定要做一次恢复演练。演练不用在生
1. 为什么备份与迁移是 Dify 落地的必修课把 Dify 跑起来不算本事能把它的数据安全地搬走、在另一个环境里原样跑起来才算真正把这块技术吃透了。我见过太多团队在测试环境里玩得风生水起一到要换服务器、要做容灾、要给客户做私有化交付的时候直接傻眼——工作流丢了、知识库对不上、对话记录全没了最后只能从头再搭一遍。这种痛踩过一次就再也不想踩第二次。Dify 这个平台本质上是一个“有状态”的应用。它不像一个纯前端页面拷个文件夹就能跑。它背后挂着关系型数据库、缓存、向量库、文件存储这一整套东西任何一个环节没搬对迁移过去就是一堆报错。所以这篇文章我想聊的就是怎么把 Dify 从一台机器完整地搬到另一台机器怎么在单机环境下做好容灾以及怎么在开发、测试、生产这些不同环境之间做无缝迁移。适合谁看如果你正在用 Docker Compose 部署 Dify或者准备把它交付到客户的内网环境又或者你只是单纯担心哪天服务器挂了数据找不回来那这篇内容应该能帮到你。我会把整个思路拆开讲包括为什么要这么备份、每一步在干什么、参数怎么定、坑在哪里。不堆概念只讲能直接抄作业的东西。2. 先搞清楚 Dify 到底存了哪些数据2.1 四类核心数据一个都不能少很多人做备份的时候只盯着数据库觉得把 PostgreSQL 导出来就万事大吉了。实测下来这种想法会让你在恢复的时候哭出来。Dify 的数据至少分成四块每一块的备份方式和恢复优先级都不一样。第一块是关系型数据库默认用的是 PostgreSQL。这里面存的是最核心的元数据应用配置、工作流编排的节点和连线、提示词、模型供应商的密钥、用户账号、租户信息、对话会话和消息记录。可以说数据库就是 Dify 的大脑丢了它等于从零开始。第二块是向量数据库常见的是 Weaviate 或者 Qdrant。知识库里的文档被切分、向量化之后就存在这里。它和关系库是配合关系——关系库里存的是知识库的“目录信息”向量库里存的是实际的向量和分片内容。两者必须配套单独恢复一个没有意义。第三块是文件存储默认落在本地的一个 volumes 目录里。用户上传的原始文档、生成的图片、导出的文件都在这里。这块最容易被忽略因为它在容器里看起来不起眼但一旦丢失知识库里的文档就变成了“有索引没原文”的空壳。第四块是配置文件和环境变量也就是.env文件和docker-compose.yaml。这里面有数据库密码、密钥、存储路径、各种开关。迁移到新环境时如果这些配置对不上服务根本起不来。我习惯把这两个文件单独拎出来做版本管理改一次记一次。2.2 数据之间的依赖关系理解依赖关系才能理解恢复顺序。打个比方数据库像是图书馆的借阅目录向量库像是书架上的书文件存储像是书里的具体内容。你恢复的时候如果先恢复目录再恢复书最后发现书的内容对不上那就白干了。正确的逻辑是先恢复基础设施数据库和向量库的服务本身再恢复数据内容最后校验一致性。具体来说PostgreSQL 和向量库要先能正常启动然后把各自的备份导入进去文件存储直接拷贝回对应目录最后启动 Dify 的应用容器让它自己去连接这些服务。顺序错了应用容器会因为连不上依赖而反复重启日志里全是连接超时。还有一个细节数据库里的租户 ID、应用 ID 这些主键在迁移前后必须保持一致。如果你用pg_dump导出再导入默认是保留这些 ID 的没问题。但如果你手动改过数据或者用了某些会重新生成 ID 的工具那向量库里的关联就会断掉。这一点在做跨环境迁移时尤其要注意。3. 单机容灾把备份做成自动化3.1 备份策略怎么定单机环境下最怕的就是磁盘坏了或者误删了数据。我的建议是“本地快照 异地导出”双保险。本地快照用文件系统或者云厂商的磁盘快照功能恢复快但防不了整机故障。异地导出就是把备份文件传到另一台机器或者对象存储上防的是灾难性故障。备份频率取决于你的数据变化速度。如果是内部测试用每天一次足够了。如果是生产环境对话记录一直在写那数据库最好做到每小时一次增量每天一次全量。向量库的变化相对少因为知识库不会天天重建可以跟着数据库一起做。这里有个经验值数据库全量备份的时间窗口要避开业务高峰。PostgreSQL 的pg_dump在数据量大的时候会锁表虽然 Dify 的并发一般不高但保险起见还是放在凌晨做。向量库的备份更重Weaviate 的备份接口会占用较多 IO也要错峰。3.2 用脚本把备份串起来手动备份迟早会忘所以一定要写成脚本挂到定时任务里。下面这个脚本是我自己在用的简化版思路是先把数据库导出来再把向量库和文件目录打包最后统一压缩加时间戳。#!/bin/bash # dify_backup.sh BACKUP_DIR/data/backups/dify DATE$(date %Y%m%d_%H%M%S) mkdir -p $BACKUP_DIR/$DATE # 1. 备份 PostgreSQL docker exec dify-db pg_dump -U postgres dify $BACKUP_DIR/$DATE/dify_db.sql # 2. 备份向量库数据目录以 Weaviate 为例 docker run --rm -v dify_weaviate_data:/data -v $BACKUP_DIR/$DATE:/backup alpine \ tar czf /backup/weaviate_data.tar.gz -C /data . # 3. 备份文件存储 docker run --rm -v dify_storage:/data -v $BACKUP_DIR/$DATE:/backup alpine \ tar czf /backup/storage.tar.gz -C /data . # 4. 备份配置文件 cp /path/to/dify/.env $BACKUP_DIR/$DATE/ cp /path/to/dify/docker-compose.yaml $BACKUP_DIR/$DATE/ # 5. 打包整体 cd $BACKUP_DIR tar czf dify_backup_$DATE.tar.gz $DATE rm -rf $DATE这个脚本里有几个点值得说。第一我用docker run --rm起一个临时容器来打包 volume这样不用去宿主机上找 volume 的真实路径兼容性更好。第二数据库导出用的是pg_dump而不是直接拷数据目录因为直接拷文件在数据库运行时会不一致导出的 SQL 才是逻辑一致的。第三配置文件和数据放在一起恢复的时候不会漏。提示pg_dump导出的文件是纯文本 SQL体积可能比较大。如果数据量上去了可以加-Fc参数导出成自定义格式体积小且支持并行恢复但恢复时要用pg_restore。3.3 恢复演练比备份本身更重要备份文件躺在那里你永远不知道它能不能用。我踩过的坑是备份脚本跑了大半年真到要恢复的时候发现向量库的 volume 名字写错了备份出来的是个空目录。所以每隔一段时间一定要做一次恢复演练。演练不用在生
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
