官宣：Milvus-backup 0.6 发布，Milvus 备份恢复提速 1.6 倍

在 Milvus 集群迁移、故障恢复或测试环境搭建中，备份和恢复都是常见操作。但备份成功之后，数据距离能够正常查询，还需要经过导入、索引重建和加载等步骤。比如对大规模向量数据来说，索引重建尤其耗时。

为了加速备份恢复的效率，最近我们正式推出了milvus-backup 0.6。

借助该能力，在 Milvus 3.0.1 上，恢复不再受导入链路中 datanode 扫描文件速度的制约，并且索引文件可以随数据一并恢复，实测恢复提速 1.6 倍；

配置文件也迎来 v2 结构化重构，并附带一键迁移命令。

以下是本次更新速览。

01 

更新速览：恢复更快、配置更简、进度更清晰

1.1恢复更快

在 Milvus 3.0.1 之前，恢复 binlog 要经 Milvus 的 import 任务重新逐行读入，并在数据恢复后重建索引。数据规模较大时，读取数据和构建索引都会占用较长时间。

在 Milvus 3.0.1 及以上版本中，milvus-backup 可以使用 snapshot 格式。恢复只是复制文件，并且数据文件与索引文件一起恢复，恢复完成即可加载使用，不再需要 datanode 逐行扫描。

我们在内部环境中，对同一数据集（3 个 collection × 1000 万行 × 768 维向量，约 92 GB，索引总量约 32 GB）进行了恢复测试：

在这组测试中，snapshot 的恢复速度约为 binlog 的1.6 倍，耗时减少约36%，并且包含了索引文件的恢复。恢复完成后，可以直接进入 collection 加载和查询验证阶段。

来，我们还会进一步优化 snapshot 格式的恢复速度。

1.2配置更简

此外，自 backup 发布以来，配置太过复杂难懂是社区反馈最集中的地方：平铺的键看不出层级关系、tlsMode 用 0/1/2 表意费解、环境变量和配置文件混在一起，谁覆盖谁的行为不透明……

在 0.6 中我们把配置重新组织，并明确了覆盖优先级：http request > --set > env > 配置文件 > 默认值。

1.3 进度清晰

过去，判断一个备份的进度通常只能看见滚动的日志，在 0.6 的最新版本中，我们给大部分耗时任务都加上了进度条，让整个任务的进度更透明。

02 

更新教程

第一步：迁移配置，确认实际生效的参数

如果你已经使用 milvus-backup，可以先迁移现有配置。0.6 仍然兼容 v1 配置，不需要手动逐项改写：

milvus-backup config migrate --config backup.yaml -o backup-v2.yaml

命令会生成新的配置文件，并输出迁移报告。需要人工调整的内容，例如环境变量变化，会在报告中列出。

v2 配置按用途重新组织了参数：

部分参数也改用了更明确的取值。例如，旧版的 milvus.tlsMode: 0/1/2，调整为 milvus.grpc.tlsMode: disabled/server/mutual，可以直接看出当前采用的 TLS 模式。

当备份与 Milvus 使用同一套存储服务时，backup.storage 中大部分未设置的参数会继承 milvus.storage，减少重复配置。rootPath 使用独立的默认值 backup，需要根据备份目录规划确认。

迁移后，执行以下命令，查看最终生效的配置及其来源：

milvus-backup config show--config backup-v2.yaml

这一步适合用来排查“修改配置后没有生效”的问题。0.6 明确了配置覆盖优先级，从高到低依次为：

HTTP request > --set > 环境变量 > 配置文件 > 默认值

如果某个参数与预期不同，可以先检查是否存在更高优先级的设置。

另外，v2 只保留凭据类环境变量，例如 MILVUS_USER、MILVUS_PASSWORD。旧版中用于设置其他参数的环境变量，需要按照迁移报告调整。

此外，考虑到配置文件人工翻译复杂易错，我们还提供了一键迁移命令：迁移命令会翻译并输出新的配置文件。

milvus-backup config migrate --config backup.yaml -o backup-v2.yaml

milvus-backup config show        # 查看最终生效配置

第二步：创建备份，使用 snapshot 格式

下面以默认数据库中的 demo_vectors collection 为例，完成一次备份与恢复。请将名称替换为实际使用的 collection。

先检查 Milvus 和存储连接：

milvus-backup check--config backup-v2.yaml

检查通过后，创建备份：

milvus-backup create \

  --config backup-v2.yaml \

  -n tutorial_backup \

  --filter demo_vectors

milvus-backup 会自动探测 Milvus 版本。在支持 snapshot 的版本上，默认自动选择 snapshot；旧版本则使用 binlog，通常不需要手动配置。

如果需要继续使用 binlog，例如与现有流程保持一致，可以在创建备份时显式指定：

milvus-backup create \

  --config backup-v2.yaml \

  -n tutorial_binlog_backup \

  --filter demo_vectors \

  --format binlog

需要注意，snapshot 的收益取决于 Milvus 版本和备份格式，仅升级 milvus-backup，并不会将已有的 binlog 备份转换为 snapshot。

第三步：恢复副本，验证数据和查询

备份完成后，可以为恢复出的 collection 添加后缀，方便与原 collection 对照：

milvus-backup restore \

  --config backup-v2.yaml \

  -n tutorial_backup \

  -s _recover

本例会恢复出 demo_vectors_recover。

恢复任务完成后，使用 Milvus 客户端检查 schema、数据行数和索引状态，再加载 collection，执行一组固定查询，确认恢复结果符合预期。

如果要评估恢复性能，建议分别记录两个时间点：

• 恢复任务完成的时间；
• collection 加载完成、查询验证通过的时间。

前者反映工具的恢复耗时，后者更接近业务实际需要的恢复时间。对于集群迁移和故障恢复，后一个指标更有参考价值。

根据备份用途选择参数预设

完成基本的备份与恢复后，还可以根据使用目的选择场景预设。0.6 在 create 命令下新增了三个选项：

这些预设让备份用途有了明确的入口。后续版本还会进一步根据场景，自动决定是否备份索引、是否压缩等参数。

升级现有脚本时，还需要修改什么？

如果你已经在定时任务或运维平台中使用 milvus-backup，除了迁移配置，还需要检查命令行参数。0.5 中已经弃用的 flag，在 0.6 中被移除：

从源码构建的用户，还需要将 Go 环境升级至 1.26。

建议先用一个 collection 完成配置迁移、备份、恢复和查询验证，再更新现有自动化任务。这样既能确认脚本兼容性，也能测出当前环境中的恢复时间，为后续迁移或故障恢复提供依据。

完整变更请参阅v0.6.0 Release notes：https://github.com/zilliztech/milvus-backup/releases/tag/v0.6.0。

作者介绍

黄浩原

Senior Software Engineer at Zilliz

文章来自于"Zilliz"，作者 "黄浩原"。