备份这件事的原则没变，还是 3-2-1：三份副本、两种介质、一份异地。 但当系统里多了 AI 组件之后，清单变了——**有些东西体积巨大却不必备份，有些东西只有几 KB 但丢了就彻底没了。** 分不清这两类，要么浪费存储，要么关键时候发现少了一环。 ## 先分清：可重放 vs 不可重放 判断标准只有一条：**这个东西能不能用确定的步骤重新得到？** 能的，叫可重放，备份它是浪费；不能的，必须备。 ## 不用备份的 **模型权重**。开源模型的权重从发布源重新下载即可，几十 GB 的备份成本远高于重新拉取。前提是：**记清楚用的是哪个模型的哪个精确版本**（含量化和 revision hash）。 **向量库的原始索引**。只要有原始文档和嵌入脚本，索引可以完全重建。注意重建要花时间和算力，所以这条取决于你能接受多长的恢复时间——能接受几小时，就不必备。 **依赖包镜像**。有锁文件和源，重装即可。 ## 必须备份的 **微调产物（LoRA / adapter）**。这是拿你的数据和算力换出来的，无法从任何地方重新下载。**这是 AI 项目里最容易丢、也最痛的一项**，而且体积通常只有几十到几百 MB，备份成本极低——没有任何理由不备。 **训练与标注数据**。尤其是人工标注的部分，那是最贵的成本。 **提示词与配置**。系统提示词、工具定义、重排阈值、切分参数……这些是**系统的实际行为定义**，几 KB 大小，丢了就只能靠记忆重建，而重建出来的肯定不一样。应当纳入版本管理。 **嵌入模型的版本标识**。容易被忽略：换模型不重新嵌入，整个向量库就废了。所以要把「当前库是用哪个模型生成的」记下来，和库放在一起。 **评估测试集**。那 30 到 50 个标注好的问题，是你能判断系统变好还是变坏的唯一依据。 ## 环境可复现 比备份文件更稳的做法是**让环境本身可重建**： - 依赖精确锁版本（`requirements.txt` / lock 文件，不要写 `>=`）； - 模型标识精确到 revision； - 部署用镜像或 IaC 脚本描述，而不是靠一台手工配好的机器。 做到这一点，「恢复」就变成了「重新跑一遍脚本」，而不是考古。 ## 演练：没验证过的备份不算备份 这话被说烂了，但 AI 系统里它尤其成立——因为环节多，任何一环对不上就恢复失败。 最小可行的演练： 1. 找一台干净的机器； 2. **只凭备份和文档**恢复整套服务； 3. 跑一遍评估测试集，对比恢复前后的指标。 演练中你会发现文档缺失、脚本依赖了某台机器的手工配置、某个路径是硬编码的。这些问题在真出事那天会变成灾难，平时花两小时能全部暴露出来。 ## 一个具体清单 给自己系统做备份规划时，按这张表过一遍： | 项目 | 备份? | 原因 | |---|---|---| | 原始文档/数据 | 必须 | 不可重放 | | 标注数据 | 必须 | 人工成本高 | | 提示词与配置 | 必须 | 行为定义，体积小 | | 评估测试集 | 必须 | 判断标准 | | 微调产物 | 必须 | 无法重下 | | 向量索引 | 可选 | 可重建，看 RTO | | 模型权重 | 不必 | 可重下 | | 依赖包 | 不必 | 可重装 | ## 小结 AI 组件的加入没有改变备份的原则，只是让「什么东西值得备」的答案变了：**备那些花时间、花钱、花人力才得到的，不备那些能重新下载的。** 微调产物、提示词配置、测试数据——这三样体积小、价值高、丢了无法恢复，是 AI 项目备份清单里最该优先确认的。