LLMOps备份：微调权重、向量库

LLMOps 里最容易被忽略的就是备份策略。
很多人只备份了模型文件，结果微调权重、向量库或训练数据集丢失后，整个项目无法恢复到可用状态。
其实这三类数据必须分开备份，因为它们的变更频率、存储格式和恢复方式完全不同：数据集决定基线，微调权重决定当前能力，向量库决定私域知识检索结果。
本文会按零基础可执行的方式，讲清楚分开备份的命令、定时任务和验证方法。

为什么要拆成三套独立备份

微调权重、向量库、数据集如果混在一起备份，会遇到几个实际问题：

• 数据集通常放在 Git 或对象存储中，变更不频繁，但体积可能很大。
• 微调权重是模型训练产生的二进制文件，动辄几个 GB，而且版本更新很快。
• 向量库保存的是文本切块后的 embedding 数据，数据库文件可能损坏，有时还需要和原始文档一起才能恢复。

如果合并成一个快照，每次备份都会浪费大量存储，恢复时也要全部拉回来。
所以建议独立备份，不同数据使用不同频率和保留策略：数据集按版本备份，权重按训练节点备份，向量库按增量周期备份。

备份前需要准备什么

开始操作前，先确认几项基础环境：

1. 确定三类数据的存放路径，例如 /data/datasets、/data/models、/data/vector_store。
2. 准备一块独立的备份存储，比如另一块云盘、NAS 或对象存储 bucket。
3. 安装常用的备份工具：rsync、restic 或 rclone。以 Ubuntu/Debian 为例。

sudo apt update
sudo apt install -y rsync restic rclone

1. 给备份目录设置合理的权限，避免使用 root 直接跑业务备份。

分步备份：权重、数据集、向量库各自怎么操作

下面按三块分别说明，每一步都给出命令和验证方式。

1. 微调权重备份

微调权重文件一般以 .bin、.safetensors 或整个模型目录形式存在。
最简单的方式是使用 rsync 做增量同步，并在每次训练结束后触发一次快照。

rsync -av --delete /data/models/ /backup/models/latest/
cp -a /backup/models/latest /backup/models/model-$(date +%Y%m%d-%H%M%S)

第一行把当前权重同步到 latest 目录，第二行生成带时间戳的副本。
注意 --delete 会删除源端已不存在的文件，如果模型文件被误删，latest 也会同步删除，所以必须保留历史快照。
也可以直接用 restic 管理版本，自动去重和加密。

restic backup /data/models --tag weights
restic snapshots

2. 数据集备份

数据集如果是 Git 仓库，直接推送到远端仓库就完成了一次备份。
如果是普通目录，建议先打包再上传对象存储。

tar -czf datasets-$(date +%Y%m%d).tar.gz -C /data datasets
rclone copy datasets-*.tar.gz remote:backup/datasets/

数据集变更不频繁，建议按版本号或日期保留最近 10 个版本即可，没必要每天做完整备份。

3. 向量库备份

向量库根据选型不同，备份方式略有差别。
以常见的 Chroma 和 Milvus 为例：

• Chroma：直接备份持久化目录。

rsync -av /data/vector_store/chroma/ /backup/vector_store/chroma/

• Milvus：建议使用官方工具 milvus-backup，或者直接备份底层的 etcd 和存储目录。

# 以 Milvus 为例，先创建备份 API 请求
curl -X POST http://localhost:8080/api/v1/backup/create -d '{"collection_names": ["doc_chunks"], "backup_name": "backup_$(date +%s)"}'

注意备份前最好暂停写入或使用向量库自身的快照功能，避免备份到不一致的数据。
如果向量库有内置导出功能，优先使用官方工具，不要直接复制正在运行的数据库文件。

设置自动定期备份

手动备份只能作为临时手段。
要实现“分开定期备份”，用系统的 crontab 就能完成。
编辑计划任务：

crontab -e

写入以下内容，分别设置不同频率：

# 每周日凌晨 2 点备份数据集
0 2 * * 0 /usr/local/bin/backup_datasets.sh

# 每天凌晨 3 点备份微调权重
0 3 * * * /usr/local/bin/backup_weights.sh

# 每 6 小时备份一次向量库（业务频繁变动）
0 */6 * * * /usr/local/bin/backup_vector_store.sh

把三个备份脚本分别写好，并且给脚本增加执行权限。
注意 cron 的环境变量比终端少，脚本里最好写成绝对路径，并加上日志输出：

./backup_weights.sh >> /var/log/llmops_backup.log 2>&1

避坑指南和恢复验证

备份做完了不等于安全，下面这些坑经常导致恢复失败：

• 只备份 latest，没有历史版本。如果权重被污染，latest 也无法恢复，必须保留多个时间点快照。
• 向量库备份时没有停止写入，导致恢复后数据不完整或损坏。备前先暂停服务，或者使用官方一致性快照。
• 忽略 object store 的版本控制。如果 rclone 上传覆盖了同名文件，旧版本可能丢失。建议开启对象存储的版本控制或多版本前缀。
• 没有做恢复演练。定期备份，却不定期恢复验证，等于白背。每月至少随机挑一个备份文件恢复到临时目录，检查权重文件能否加载、向量库能否正常查询。

验证微调权重恢复的简单办法：

python -c "import torch; m = torch.load('/backup/models/model-20250101/pytorch_model.bin', map_location='cpu'); print('权重加载成功')"

向量库验证：用备份目录启动一个新的实例，执行一次相似度查询，看返回结果是否正常。

如果你正在处理 LLMOps 备份：微调权重、向量库、数据集分开定期备份，建议先按本文步骤完整执行，再根据自己的环境做微调；
遇到异常时优先回看避坑和高频问题部分。
另外，备份脚本要设置执行成功或失败的通知，可以把日志接入企业微信或钉钉机器人，确保备份挂了能第一时间知道。

常见疑问：

• 模型文件很大，每次都全量备份太占空间怎么办？

优先使用 restic 或 rclone 的增量功能，它们在远端只存储变化的部分，能大幅减少存储和带宽成本。

• 向量库备份必须和数据集保持一致吗？

强烈建议保持同一个时间点的快照。
如果向量库和数据集不一致，恢复后的问答结果会出现新旧信息混杂。
备份时先记录数据集版本，再备份向量库，恢复时按同一版本还原。