疯狂的SRE

深色模式

向量库备份与扩缩容 ​

摘要：本文面向负责向量库可靠性的 SRE。覆盖三大主流库的生产备份手段——Milvus 的 milvus-backup 工具（全量）、Qdrant 的快照 API（单节点与分布式每节点一份）、Weaviate 的快照/备份——以及扩缩容、分片、RTO/RPO 设计与演练。明确标注「增量备份不支持」「恢复需同版本或更新」等约束（来源：zilliztech/milvus-backup、particula Qdrant 快照、CSDN milvus-backup 实践，访问 2026-10-09，[版本相关]/[未实测] 已标注）。

核心概念 ​

向量库的「数据」= 原始向量 + 标量 payload + 索引（索引可重建，但耗时）。备份策略分两类：

手段粒度增量适用
对象存储级拷贝（MinIO/S3 bucket）整库依赖底层Milvus 底层
向量库原生备份/快照集合/集合级多数不支持三者通用
逻辑导出（客户端 scroll 全量）集合否跨版本迁移

多数向量库不支持增量备份

milvus-backup 只做全量 copy + 全量 restore，无增量/差量/去重（feature request 仍 open，2025-08 提，来源：particula，访问 2026-10-09）。Qdrant 快照同理是整集合点快照。规划容量与备份窗口时按全量算。

架构与原理：备份与恢复链路 ​

恢复约束（来源：particula、cmdschool，访问 2026-10-09）：

  • Milvus：milvus-backup 备份支持 2.2+，恢复支持 2.4+；只能恢复到相同或更新版本，不支持降级。
  • Qdrant 分布式：每个节点、每个集合都要单独快照；单节点快照只含该节点分片数据。

生产实践一：Milvus 用 milvus-backup ​

下载工具与 backup.yaml（示例，版本相关），配置指向 Milvus 的 etcd 与 MinIO：

bash
# 校验配置
milvus-backup check --config /etc/milvus-backup/backup.yaml
# 全量创建
milvus-backup create --config /etc/milvus-backup/backup.yaml
# 列出
milvus-backup list --config /etc/milvus-backup/backup.yaml
# 恢复（新建集合后缀示例）
milvus-backup restore -n my_backup -s _recover --config /etc/milvus-backup/backup.yaml
# 覆盖原集合恢复（先 drop 原集合）
milvus-backup restore -n my_backup --drop_exist_collection true --config /etc/milvus-backup/backup.yaml

backup.yaml 关键项（来源：cmdschool / CSDN milvus-backup，访问 2026-10-09）：

yaml
# /etc/milvus-backup/backup.yaml（节选，[版本相关]）
milvus:
  address: localhost
  port: 19530
storage:
  type: minio
  bucketName: a-bucket          # docker-compose 安装默认 a-bucket；Helm/Operator 为 milvus-bucket
  rootPath: files
  # accessKeyID / secretAccessKey / endpoint 按你的 MinIO 填

定时备份（每天 3 点，保留策略见脚本逻辑）：

bash
# crontab: 0 3 * * * bash ~/scripts/backup-milvus.sh
# 脚本内：check -> create -> list -> 删 7 天外(周日保留 30 天)

备份桶权限与加密

备份落 MinIO/S3，必须服务端加密（SSE）并对桶做访问收敛；备份含全部向量与 payload，泄露等同数据泄露。备份桶与生产桶分离账号/策略。

生产实践二：Qdrant 快照（单节点 + 分布式） ​

单节点创建快照并下载（REST）：

bash
# 触发快照
curl -X POST http://localhost:6333/collections/kb_v1/snapshots
# 列出
curl -s http://localhost:6333/collections/kb_v1/snapshots
# 下载
curl -O http://localhost:6333/collections/kb_v1/snapshots/<snap_name>

CLI 恢复（单节点）：

bash
# 注意：--force-snapshot 才允许覆盖已存在集合（文档写下划线，panic 用连字符，按 CLI 实际）
qdrant-client snapshot recover <snap_name> --collection kb_v1 --force-snapshot

分布式：每个节点一份快照

三节点集群 × 四个集合 = 每次恢复点 12 个归档。单节点 REST 调用只抓该节点分片；恢复须把每份归档放回对应服务该分片的节点（来源：particula，访问 2026-10-09）。备份 Job 要 fan-out 到每个节点并登记「谁产出的归档」。

生产实践三：Weaviate 备份 ​

Weaviate 支持快照与备份（含 S3/GCS 后端，版本相关）。基本形态：

bash
# 创建备份到指定后端（示例，[版本相关]，以官方 backup API 为准）
curl -X POST http://localhost:8080/v1/backups/filesystem/weaviate-bk-20261009 \
  -H "Content-Type: application/json" \
  -d '{"include":"DevDoc"}'

版本与模块影响备份

Weaviate 备份 API 字段、后端支持随版本变化（1.25/1.26 有差异）；含模块（text2vec/generative）时确认备份是否覆盖模块配置。生产前在 staging 实测一次完整恢复（来源：weaviate 文档，访问 2026-10-09，[未实测]）。

扩缩容与分片 ​

  • Milvus：组件独立扩；QueryNode 负责检索、DataNode 写入、IndexNode 建索引。小于 10M 用 standalone，避免分布式复杂度（来源：echoesofthemachine，访问 2026-10-09）。
  • Qdrant：集群模式加分片；低于约 10 亿/集合时单集群最省心，超大规模需评估（来源：echoesofthemachine、aicoolies，访问 2026-10-09，[未实测]）。
  • Weaviate：raft 复制保证副本；Dynamic 索引省多租户内存。

分片数一旦设定难改

Qdrant/Milvus 分片数通常在集合创建时定，运行期重分片需「scroll 读出 → 新建分片集合 → 写回」的迁移（来源：johal Qdrant 1.11 实践，访问 2026-10-09）。预估 1–2 年增长再定分片，避免频繁迁移。

验证 ​

bash
# 恢复后必须校验：集合存在 + 索引重建 + recall 不回归
python - <<'PY'
from pymilvus import MilvusClient
c = MilvusClient("http://localhost:19530")
assert c.has_collection("docs_v1_recover")
# 抽样 query 比对恢复前后 top-k 一致性（召回回归检查）
PY
# Qdrant: 恢复后 query 返回且带过滤无越权
# Weaviate: /v1/.well-known/ready + 抽样 hybrid query

回滚与清理 ​

恢复是覆盖性操作

恢复会重建/覆盖集合，先确认备份完整、目标可覆盖或新建别名集合。Milvus 用 -s _recover 新建集合灰度比对最安全；Qdrant 单节点恢复须 --force-snapshot 才会覆盖。清理旧备份按保留策略（如 7/30 天）自动化，避免桶无限膨胀。

故障排查 ​

  • Qdrant 恢复后集合为空：未加 --force-snapshot 且目标集合已存在 → 工具直接退出而非静默替换（来源：particula，访问 2026-10-09）。加该 flag，注意连字符写法。
  • Milvus 恢复版本不兼容：恢复到更旧版本不支持 → 只能恢复到 ≥ 备份版本。
  • 备份桶权限错：SSE / IAM 配置不当导致 create 成功但 list/restore 失败 → 备份后立即做一次 list + 抽样 restore 验证。
  • 分布式恢复错位：归档放错节点 → 恢复后缺分片数据 → 严格登记归档来源节点。
  • 恢复后召回掉：索引未重建或量化配置不同 → 恢复后显式重建索引并跑 recall 校验。

安全与合规 ​

  • 备份即敏感数据：向量 + payload 含业务语义，备份桶须加密、最小权限、与生产隔离；跨区复制遵守数据驻留法规。
  • 恢复演练的权限：执行恢复的账号应受限且审计；演练环境用脱敏/采样数据，避免把生产备份拉到弱管控环境。
  • 销毁：过期备份按合规要求安全删除（对象存储版本清理 + 生命周期），防残留泄露。

成本与性能 ​

量级参考，非实测。

  • 备份成本：全量备份 = 向量 + payload + 索引元数据体积；对象存储成本低但需算网络出口与恢复时间。无增量 → 大数据量备份窗口长，按全量规划。
  • 恢复 RTO：取决于数据量、索引重建耗时；Milvus 社区实践单集合恢复可达分钟~十分钟级（来源：cmdschool 示例 195s，访问 2026-10-09，[未实测]），需你环境实测定 SLA。
  • RPO：由备份频率决定（如每天 3 点 = 最坏丢 1 天）；高变更集合可缩短间隔或加 WAL/双写。
  • 扩缩容成本：Milvus 分布式组件多，扩容 YAML/Operator 成本低但理解成本高；Qdrant/Weaviate 单集群更轻。

参考资料 ​

基于 VitePress 构建 · 托管于阿里云 ECS

Copyright © 2026 CrazySRE