Dify本地部署（六）全量备份、还原

书接上文：前五章列举了核心的知识库、智能体创建、模型供应商添加等问题，本章针对全量数据备份还原新服务器进行说明
（先点赞、保存、收藏指不定哪天就用上了）

---

提示：目前针对多种类型服务器备份还原版本为：V0.15.3 其他版本按照下文方案若有相应问题，欢迎各位评论区指出 ！！！ 目前从源码及相关路径映射获知，除非源码大版本更新优化 基本均可适用

---

前言

过程部署及dify启动问题翻看之前文章，本文不对单独赘述，只标记干货，官网最权威，若过程中有不理解或疑问，评论、私信均可指出。

---

一、备份思路？

该图为官网针对版本升级的数据迁移，但其实从现有企业级使用的角度来看，或者国内针对开源软件的眼光来看，基本不关注边缘或者附属功能，核心功能能用、能跑即可，尤其是在使用一段时间后，迁移导致的使用风险逐步加大，基本很少做升级，但也除非可能哪一个大版本有比较炸裂的功能。那如果是我，那还不如重新部署一个新的，指不定哪一个仁兄在前几年搭了一个炸弹在那边，哈哈哈。收！

基本上官网针对备份还原尤其是同一个版本服务器迁移属于0.那么我企业级的东西肯定还是要基于解决方案进行宣传的嘛，那么这个迁移、还原的需求我认为其实还是有的。

1.数据备份

​​​​
最开始的思路

数据
+
镜像
+
配置文件

那我觉得其实将数据导出成为一个bak或者sql文件
镜像直接做一个压缩包
配置文件现有环境均有

我认为这三块基本上就全了 然后轻松秒杀

2.预判的风险

在最开始构思的时候，我觉得有这三步其实也就够了，但过程中有一个问题衍生出来。目前不管是自建模型还是运营商模型，均有相关的密钥，我其实翻了相关官网文档，针对该处的标记基本也属于0，代码都没翻出来，也有可能走马观花。。。

埋一个伏笔 下节开奖

二、过程尝试

1.数据备份

将现有postgres数据导出还原
本地向量库导出还原（不会导出的，往后看）
（不重要）

2.镜像备份

镜像压缩包制作（这块直接压缩一个整包）

docker save -o  allimages.tar  images1:v1 images2:v2 ....

该镜像等于就是你当前环境针对dify需要的镜像包做的多合一，
（后边会用到）
（为何我要打包，因为我目标服务器没有网络环境，衙门的都是单台自己跑，网络别想）

3.开始还原

那还是参考前文中列举的启动方式。
安装docker docker-compose
load <加载镜像
运行dify源码
然后把你自己的sql文件导出

4.结果！

我自己亲测哦
结果就是：开奖（前文有伏笔）
首先就是
现有的智能体能加载（这一块我自己到yaml文件手工就能做，相较于用数据库去做 不亚于脱裤子放屁）
现有的知识库基本上是一塌糊涂，不仅不全，而且基本看不成，完全还要重新整理
另外最严重的就是 模型供应商 也就是我之前加载的 私钥（api-key）完全没有，点开就报错 （我可以涵盖 哪怕我换供应商 我删除总比自己加要省时间）

我最开始的想法是全量备份，我要拷贝一个一摸一样的。所有的所有

所以基本上属于上属于白忙活 不白忙活，可口可乐卖了北极熊的肖像权，冰川项目赚大发..... 又跑题了

三、终极解决方案

简单粗暴上方案：备份还原 volumes 文件夹

对 ！ 你没看错就是它
合着看了五六分钟都浪费时间了
我折腾上边折腾了快一天的！！！
但是按照这个方案，确实是最满足的我的需求想法的。一点都不会缺，哪怕是访问记录都最全。

目前确实不算是最优解，但是绝对是最快的 ！！！早早下班不香么

四、脚本澄清