在 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
命令会生成新的配置文件，并输出迁移报告。需要人工调整的内容，例如环境变量变化，会在报告中列出。部分参数也改用了更明确的取值。例如，旧版的 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.yamlmilvus-backup config show # 查看最终生效配置
第二步：创建备份，使用 snapshot 格式
下面以默认数据库中的 demo_vectors collection 为例，完成一次备份与恢复。请将名称替换为实际使用的 collection。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