简介本资源为 Milvus 2.5.4 单节点版离线安装包面向需要在无外网环境下快速搭建向量数据库的开发者与数据科学家尤其适合开发测试与小规模应用场景。压缩包共 10 个文件约 779.13MB以 gz 镜像与二进制包为主辅以 docker-compose.yml、yaml 配置、requirements.txt 依赖清单及 save_image.py 脚本并集成 milvus-backup 备份工具与 minio-binaries 对象存储组件形成一站式部署方案。已有 1372 人学习下载。借助该包读者可直接完成 Milvus 与 MinIO 的安装配置利用 milvus-backup 实现数据备份与快速恢复保障向量数据安全同时可通过 API 将 Milvus 集成到图像识别、推荐系统、自然语言处理等机器学习工作流中体验向量索引热更新与相似度检索能力省去单独下载部署各组件的繁琐步骤。1. 离线环境下的 Milvus 2.5.4为什么一个压缩包能省掉三天折腾在内网隔离的服务器上部署向量数据库最让人头疼的从来不是数据库本身而是它背后那一长串依赖。Milvus 2.5.4 这个版本把 standalone 模式、milvus-backup 备份工具和 minio-binaries 对象存储打包成一个离线安装包本质上解决的就是「机器不能出网、但我要跑起一套完整的向量检索服务」这个场景。我见过太多团队在能联网的开发机上十分钟跑通到了生产内网环境卡了三天——镜像拉不下来、MinIO 二进制缺失、备份工具版本对不上全是这类问题。这个包适合两类人一类是在专网、内网、边缘机房部署向量检索服务的运维和平台工程师另一类是想在本地完全离线复现一套 Milvus 环境做测试的开发者。它把 standalone 单机版、备份恢复链路、对象存储三块拼在一起你拿到手就是一个自包含的部署单元。接下来我按实际落地顺序把依赖关系、部署步骤、参数配置和踩坑点拆开讲。2. 拆开压缩包之前Milvus standalone 的依赖链与选型逻辑2.1 为什么 standalone 模式仍然需要 MinIO 和 etcd很多人第一次接触 Milvus 会有一个误解既然是单机版为什么还要依赖对象存储和分布式协调组件这得从 Milvus 的架构说起。Milvus 2.x 是存算分离设计即使是 standalone 模式它的内部组件root coord、data coord、query coord、index coord 等仍然通过 etcd 做服务注册和元数据管理通过对象存储来持久化 segment 数据和索引文件。standalone 只是把这些组件跑在同一个进程里并没有取消对外部存储的依赖。MinIO 在这里扮演的是 S3 兼容对象存储的角色。Milvus 写入的向量数据、索引文件、binlog 全部落在 MinIO 的 bucket 里。离线包里带 minio-binaries就是为了让你不用单独去下载 MinIO 服务端二进制。etcd 则负责存储集合的 schema、分区信息、segment 状态这些元数据。理解了这层依赖关系后面排查问题时你才知道该看哪个组件的日志。2.2 离线包里三个组件的版本匹配关系离线安装最怕版本错配。Milvus 2.5.4 对 etcd 和 MinIO 都有最低版本要求milvus-backup 也有自己的兼容矩阵。下面这张表是我在实际部署中验证过的组合组件版本要求作用离线包内是否包含Milvus standalone2.5.4向量检索引擎主体是milvus-backup与 Milvus 2.5.x 配套集合级备份恢复是minio-binariesRELEASE.2023 及以上S3 兼容对象存储是etcd3.5.x元数据存储与服务注册通常需单独准备注意 etcd 在很多离线包里不一定附带你需要提前确认目标机器上有没有可用的 etcd 实例。如果没有得单独准备一个 etcd 的离线二进制。这是很多人拿到包之后第一个翻车的地方——以为解压就能跑结果 Milvus 启动时报连接 etcd 超时。2.3 部署目录规划与端口分配在动手之前先把目录和端口规划好能省掉后面大量返工。我一般会按下面的结构来组织# 部署根目录规划 /opt/milvus/ ├── bin/ # milvus 可执行文件 ├── configs/ # milvus.yaml 等配置文件 ├── minio/ │ ├── bin/ # minio 二进制 │ └── data/ # minio 数据目录 ├── backup/ │ ├── bin/ # milvus-backup 二进制 │ └── configs/ # backup.yaml └── logs/ # 统一日志目录端口方面Milvus standalone 默认占用 19530gRPC和 9091metrics/健康检查MinIO 默认 9000API和 9001控制台etcd 默认 2379。这些端口在内网环境里要提前确认没有被占用尤其是 9000 这个端口经常和别的服务冲突。提示如果目标机器上已经有 MinIO 实例在跑可以复用不必非要启动离线包里的 minio-binaries。但要注意 bucket 的命名和访问密钥配置要和 milvus.yaml 里保持一致。3. 从解压到跑通Milvus 2.5.4 离线部署的完整操作链3.1 解压与目录初始化拿到压缩包后第一步是解压并确认文件完整性。不同来源的包目录结构可能略有差异但核心文件应该包含 milvus 可执行文件、配置文件模板、minio 二进制和 milvus-backup 二进制。# 创建部署根目录 mkdir -p /opt/milvus cd /opt/milvus # 解压离线安装包假设包名为 milvus-standalone-2.5.4-offline.zip unzip milvus-standalone-2.5.4-offline.zip -d /opt/milvus/ # 确认关键文件是否存在 ls -lh /opt/milvus/bin/milvus ls -lh /opt/milvus/minio/bin/minio ls -lh /opt/milvus/backup/bin/milvus-backup # 给二进制文件加执行权限 chmod x /opt/milvus/bin/milvus chmod x /opt/milvus/minio/bin/minio chmod x /opt/milvus/backup/bin/milvus-backup解压后先别急着启动用ls确认三个核心二进制都在。如果发现某个文件缺失大概率是压缩包传输过程中损坏了重新传一遍比在那里猜原因快得多。权限这一步也别省尤其是从 Windows 传到 Linux 的包执行权限经常丢失。3.2 启动 MinIO 并创建 bucketMinIO 要先于 Milvus 启动因为 Milvus 启动时会去连接对象存储。启动命令里几个关键参数--address指定 API 端口--console-address指定控制台端口数据目录指向你规划好的路径。# 设置 MinIO 的访问密钥生产环境务必改掉默认值 export MINIO_ROOT_USERminioadmin export MINIO_ROOT_PASSWORDMinio2024 # 启动 MinIO 服务后台运行 nohup /opt/milvus/minio/bin/minio server \ /opt/milvus/minio/data \ --address :9000 \ --console-address :9001 \ /opt/milvus/logs/minio.log 21 # 等待几秒后检查是否启动成功 sleep 3 curl -s http://localhost:9000/minio/health/live启动后访问http://机器IP:9001进入 MinIO 控制台手动创建一个 bucket名字比如叫milvus-bucket。这个 bucket 名字后面要填到 milvus.yaml 里。如果你不想用控制台也可以用 mc 客户端命令行创建但离线环境下 mc 不一定有手动创建最省事。注意MINIO_ROOT_PASSWORD 如果太短少于 8 位MinIO 会拒绝启动。这是很多人第一次启动失败的原因日志里会明确提示密码长度不够。3.3 配置 milvus.yaml 的关键参数Milvus 的配置文件是整个部署的核心。离线环境下需要重点改的是对象存储和 etcd 的连接信息。下面列出必须检查的几个配置段# milvus.yaml 关键配置片段 # etcd 配置 etcd: endpoints: - localhost:2379 # 如果 etcd 不在本机改成实际地址 rootPath: by-dev metaSubPath: meta kvSubPath: kv # MinIO / S3 配置 minio: address: localhost # MinIO 服务地址 port: 9000 # MinIO API 端口 accessKeyID: minioadmin # 要和 MinIO 启动时的 USER 一致 secretAccessKey: Minio2024 # 要和 MinIO 启动时的 PASSWORD 一致 useSSL: false # 内网通常不开 SSL bucketName: milvus-bucket # 提前创建好的 bucket 名 rootPath: files # 数据在 bucket 内的前缀路径 # 日志配置 log: level: info file: rootPath: /opt/milvus/logsrootPath这个参数容易被忽略。它决定了 Milvus 在 bucket 里把数据放在哪个前缀目录下。如果你之前用同一个 bucket 跑过别的 Milvus 实例rootPath 不区分开会导致数据互相干扰。我一般会按环境命名比如files-prod、files-test。3.4 启动 Milvus standalone 并验证服务状态配置改好后就可以启动 Milvus 了。启动命令本身不复杂关键是启动后要确认它真的健康而不是进程在但服务不可用。# 启动 Milvus standalone cd /opt/milvus nohup ./bin/milvus run standalone \ --config-file ./configs/milvus.yaml \ ./logs/milvus.log 21 # 等待启动完成首次启动需要初始化大约 30-60 秒 sleep 30 # 检查进程是否存在 ps aux | grep milvus | grep -v grep # 检查健康检查端口 curl -s http://localhost:9091/healthz # 查看启动日志中是否有错误 grep -i error\|panic\|fatal /opt/milvus/logs/milvus.log | tail -20健康检查返回OK说明服务基本可用了。如果返回连接拒绝先看进程在不在进程在但端口不通看日志里有没有端口绑定失败的报错进程不在日志里通常会有明确的初始化失败原因最常见的是连不上 etcd 或 MinIO。3.5 用 milvus-backup 做一次备份恢复验证部署完不验证备份链路等于给自己埋雷。milvus-backup 的配置文件需要指向 Milvus 的 gRPC 地址和 MinIO 的连接信息。# backup.yaml 关键配置 milvus: address: localhost port: 19530 minio: address: localhost port: 9000 accessKeyID: minioadmin secretAccessKey: Minio2024 bucketName: milvus-bucket backupBucketName: milvus-backup-bucket # 备份数据单独放一个 bucket rootPath: backup配置好后先创建一个测试集合然后执行备份和恢复# 创建备份假设已有一个名为 test_collection 的集合 ./backup/bin/milvus-backup create -n test_backup -c test_collection # 查看备份列表 ./backup/bin/milvus-backup list # 恢复到新集合名 ./backup/bin/milvus-backup restore -n test_backup -c test_collection_restored备份能跑通、恢复出来的集合能正常查询这条链路才算真正验证完毕。我见过只验证了 Milvus 能启动就上生产的结果真需要恢复的时候发现 backupBucketName 没配备份数据全写到了默认路径下找都找不到。4. 离线部署最容易翻车的五个地方4.1 现象Milvus 启动后立刻退出日志显示 etcd 连接超时原因通常是目标机器上没有运行 etcd或者 milvus.yaml 里的 etcd endpoints 地址写错了。离线包一般不带 etcd需要你单独准备。解决方式是先确认 etcd 服务状态systemctl status etcd或ps aux | grep etcd如果没有就部署一个 etcd 离线二进制启动后再改 milvus.yaml 指向正确的地址和端口。4.2 现象MinIO 启动报错 Unable to initialize backend: The specified key does not exist这个报错通常是因为数据目录权限不对或者指定的数据目录路径不存在。MinIO 不会自动创建多级目录你需要提前mkdir -p把目录建好并确保启动用户有读写权限。另一个可能是 MINIO_ROOT_PASSWORD 太短日志里会同时提示密码长度问题。4.3 现象Milvus 健康检查通过但插入数据时报 bucket not found原因是 milvus.yaml 里配置的 bucketName 在 MinIO 里没有提前创建。Milvus 不会自动创建 bucket它假设你已经建好了。解决方式是登录 MinIO 控制台手动创建对应名称的 bucket或者用 mc 命令行创建。创建后不需要重启 Milvus下一次写入就会成功。4.4 现象milvus-backup 执行时报 connection refused 或 context deadline exceeded先检查 backup.yaml 里的 milvus.address 和 port 是否指向了正确的 gRPC 地址。如果 Milvus 跑在容器里或另一台机器上localhost 是不通的。另外 milvus-backup 的版本必须和 Milvus 服务端版本兼容2.5.x 的 Milvus 要用配套的 backup 工具版本错配时连接握手就会失败。4.5 现象重启 Milvus 后之前创建的集合不见了这种情况大概率是 MinIO 的数据目录被清空或者 rootPath 配置变了。Milvus 的元数据在 etcd 里实际数据在 MinIO 里两者缺一不可。如果 etcd 数据还在但 MinIO 数据丢了集合的 schema 能查到但查询会报错。解决方式是确保 etcd 和 MinIO 的数据目录都做了持久化重启时不要清空。另外 rootPath 改了也会导致找不到之前的数据这个参数一旦确定就不要随意改。5. 把离线包用出长期价值版本升级与数据迁移的实操技巧离线部署跑通只是第一步真正体现工程能力的是后续的版本升级和数据迁移。Milvus 2.5.4 这个版本在 2.5.x 系列里属于稳定版但如果你后续要升到更高版本离线环境下不能直接拉镜像得走「备份-升级-恢复」的路径。具体做法是用当前版本的 milvus-backup 把所有集合备份到 MinIO 的一个独立 bucket 里然后停掉旧版本 Milvus部署新版本的离线包启动新版本后先用 milvus-backup 的 restore 命令把数据恢复进去。这里有个细节备份时用的 milvus-backup 版本和恢复时用的版本最好一致跨大版本恢复时 schema 兼容性需要提前验证。另一个实用技巧是关于 MinIO 数据目录的迁移。如果你要把整套环境从一台机器搬到另一台最稳妥的方式不是直接拷贝 MinIO 数据目录而是用 milvus-backup 做逻辑备份再恢复。直接拷贝数据目录要求两边的 MinIO 版本完全一致、etcd 数据也同步迁移任何一个环节对不上都可能导致数据不可读。逻辑备份虽然慢一点但跨机器、跨版本的可靠性高得多。还有一个我踩过的坑离线环境下 MinIO 的磁盘空间规划。向量数据的体积增长往往超出预期尤其是当集合的索引类型是 IVF 或 HNSW 时索引文件可能比原始向量数据还大。我一般会按原始数据量的 3 倍来预留 MinIO 磁盘空间并且设置一个定时任务监控 bucket 的使用量。如果磁盘写满了Milvus 的写入会直接失败而且恢复起来很麻烦——你得先扩容再重启 MinIO 和 Milvus有时候还需要手动触发 compaction 来释放空间。最后说一个习惯每次部署完离线环境我都会把 milvus.yaml、backup.yaml 和启动脚本一起打包存档标注好版本号和日期。下次再部署或者排查问题时直接拿存档的配置对比比凭记忆靠谱得多。离线环境的信息获取成本高能文档化的东西尽量文档化这是我在内网部署里最深的体会。希望帮到你。本文还有配套的精品资源点击获取