研发平台的备份保留策略，核心是先按数据对象分级，再为每一级确定保留周期、备份频率、存放位置和恢复目标，最后用定期恢复演练验证策略是否真的可用。本文给出一套可执行的制定流程，覆盖对象分级、参数设定、角色分工、示例矩阵与上线检查；旧工具数据搬迁和知识页面版本管理不在本文范围。ONES 在分级清单与演练记录的管理动作上可以承接，具体备份参数需结合部署方式与厂商确认。
要点总览（TL;DR）
- 保留策略先做对象分级，再定保留周期、备份频率、存放位置与恢复目标，顺序颠倒容易出现核心数据保留不足、可重建产物占用存储的问题。
- 分级依据可重建性、业务影响与合规要求三项，等级控制在三档，核心级覆盖代码仓库、工作项与需求、配置与权限数据。
- 保留矩阵至少写清对象、等级、保留周期、备份频率、存放位置、恢复点目标、责任人与清理规则，核心级数据不设自动清理。
- 备份任务显示成功不等于能恢复，核心级建议每季度做一次恢复演练，记录恢复时间点、耗时、结果与修正项。
- 策略上线前逐项核对对象覆盖、合规对齐、清理规则、责任人与复核周期，文档、任务配置与演练记录三者保持同步更新。
先给答案：保留策略由哪几个决定项构成
一份能执行的保留策略，需要先定四个参数：对象分级、保留周期、备份频率、恢复目标。这四个参数之间存在先后依赖——对象分级决定了哪些数据值得长期保留、哪些可以短周期清理，保留周期和备份频率又共同决定了恢复目标能否达成。跳过分级直接定“统一保留 90 天”，通常会出现两类问题：不可重建的数据保留不足，可重建的产物占用大量存储。
四个决定项的含义与设定顺序如下：
| 决定项 | 回答的问题 | 设定顺序 |
|---|---|---|
| 对象分级 | 哪些数据需要备份，各自重要到什么程度 | 第一步 |
| 保留周期 | 每一级数据保留多久后可以清理 | 第二步 |
| 备份频率 | 多久备份一次，最多能容忍丢失多长时间的数据 | 第二步，与保留周期同步确定 |
| 恢复目标 | 故障后多长时间内恢复、恢复到哪个时间点 | 第二步，由前两项推导 |
策略文档至少应包含以下字段，缺一项都会让执行环节出现歧义：对象名称与范围、等级、保留周期、备份频率、存放位置（本地/异地）、恢复点目标、恢复时间目标、责任人、清理规则、复核周期。这份字段清单可以直接作为策略文档的目录结构，后续章节的分级表、保留矩阵和演练记录都从它派生。
第一步：盘点研发平台里的数据对象并分级
盘点的目标是形成一张完整的数据对象清单，避免出现“以为备份了、实际没覆盖”的盲区。研发平台常见的数据对象包括：代码仓库及其分支与提交历史、工作项与需求记录、文档与知识页面、测试用例与缺陷记录、构建产物与制品、配置与权限数据（账号、角色、项目配置、集成凭证）。清单应按平台实际承载的对象逐项核对，而不是照抄通用列表。
分级依据建议采用三项判断：可重建性、业务影响、合规要求。可重建性指数据丢失后能否通过其他途径重新生成，例如构建产物通常可以从代码重新构建，而代码提交历史和需求评审记录一旦丢失无法复原。业务影响指数据缺失对交付、审计、客户承诺造成的实际后果。合规要求指行业或合同中对留存期限的明确规定。
| 数据对象 | 可重建性 | 业务影响 | 建议等级 |
|---|---|---|---|
| 代码仓库与提交历史 | 不可重建 | 高，直接影响交付与回滚 | 核心级 |
| 工作项与需求记录 | 不可重建 | 高，涉及过程追溯与审计 | 核心级 |
| 文档与知识页面 | 部分可重建 | 中高，影响协作与知识传承 | 重要级 |
| 测试用例与缺陷记录 | 部分可重建 | 中，影响质量追溯 | 重要级 |
| 构建产物与制品 | 可重建（从代码构建） | 中低，重建需要时间成本 | 一般级 |
| 配置与权限数据 | 不可重建 | 高，影响平台可用与安全 | 核心级 |
分级结果直接映射到保留等级：核心级对应最长保留期与最高备份频率，重要级次之，一般级以控制存储成本为主。等级数量建议控制在三档，档位过多会让执行和复核变得困难。分级表完成后应交由研发负责人与安全合规角色共同确认，确认后的版本作为策略文档的附件固定下来。
第二步：为每一级设定保留周期与备份频率
把分级结果转成参数时，需要同时考虑恢复点目标和存储成本。保留周期决定数据能回溯多远，备份频率决定故障时最多丢失多长时间的数据，两者共同构成恢复能力的边界。以下区间可作为起点，再按合规要求和实际成本调整：
| 等级 | 保留周期参考 | 备份频率参考 | 存放位置 | 恢复点目标参考 |
|---|---|---|---|---|
| 核心级 | 1 年以上，按合规要求可延长 | 每日全量或每日增量加每周全量 | 本地加异地 | 24 小时内 |
| 重要级 | 3 至 12 个月 | 每日增量，每周全量 | 本地为主，关键节点异地 | 24 至 48 小时 |
| 一般级 | 1 至 3 个月 | 每周全量 | 本地 | 一周内 |
全量与增量的取舍影响恢复速度和存储占用：全量备份恢复快、占用大，增量备份占用小、恢复时需要按链拼接。常见做法是核心级采用“每日增量加周期性全量”，一般级直接周期性全量。本地与异地的取舍取决于故障场景——本地备份应对误删和单机故障，异地备份应对机房级故障，核心级数据应同时具备两者。
存储成本与合规留存需要放在一起权衡。合规要求往往规定了最低留存期限，这部分不能压缩；超出合规要求的部分，可以按“回溯需求频率”决定是否保留。例如超过一年的构建产物如果半年内无人回溯，就可以缩短保留期。每次调整都应在策略文档中记录调整理由和生效日期，便于后续复核。
第三步：明确角色分工与交付物
策略能否执行，取决于每个环节是否有明确的责任人。建议按以下方式划分：
| 角色 | 主要职责 |
|---|---|
| 平台管理员 | 执行备份任务配置、监控备份状态、处理备份失败告警 |
| 研发负责人 | 确认数据对象分级、提出保留周期调整需求、参与演练结果评审 |
| 安全合规 | 提供合规留存要求、审核保留周期是否满足要求、参与例外审批 |
| 运维 | 保障存储与备份基础设施可用、配合异地存放与恢复环境准备 |
交付物有三类：策略文档（含分级表与保留矩阵）、备份任务配置（记录任务名称、覆盖对象、频率、存放位置）、演练记录（每次恢复演练的对象、时间点、耗时、结果与修正项）。三类交付物应互相对应——策略文档中的每一条保留规则，都能在备份任务配置中找到对应任务，在演练记录中找到验证结果。
变更与例外审批建议由安全合规角色牵头、研发负责人会签：常规参数微调可由平台管理员按策略文档执行并记录；涉及缩短核心级保留期、取消异地存放、豁免某类对象的备份等例外，必须走审批并注明有效期。例外到期后应自动回到复核流程，避免临时豁免变成长期缺口。
示例：一个中等规模研发团队的保留矩阵
以下示例为演示情景，假设条件为：约 100 人的研发团队，使用一套研发平台承载代码、需求、测试与构建，无强监管行业的特殊留存要求，存储预算有限。实际填写时应替换为自身条件。
| 对象 | 等级 | 保留周期 | 备份频率 | 存放位置 | 恢复点目标 | 责任人 |
|---|---|---|---|---|---|---|
| 代码仓库与提交历史 | 核心级 | 18 个月 | 每日增量，每周全量 | 本地加异地 | 24 小时 | |
| 工作项与需求记录 | 核心级 | 18 个月 | 每日全量 | 本地加异地 | 24 小时 | |
| 配置与权限数据 | 核心级 | 12 个月 | 每日全量 | 本地加异地 | 24 小时 | |
| 文档与知识页面 | 重要级 | 6 个月 | 每日增量，每周全量 | 本地 | 48 小时 | |
| 测试用例与缺陷记录 | 重要级 | 6 个月 | 每日增量，每周全量 | 本地 | 48 小时 | |
| 构建产物与制品 | 一般级 | 30 天 | 每周全量 | 本地 | 一周 |
清理规则按等级设定：一般级数据超过 30 天自动清理，清理前生成待删清单供平台管理员确认；重要级数据到期后进入 30 天缓冲期再删除；核心级数据不设自动清理，由安全合规角色按年度复核后决定。演练安排为：核心级每季度一次恢复演练，重要级每半年一次，一般级每年抽查一次。示例中的周期数值仅用于示范填写方式，不作为通用标准。
第四步：用恢复演练验证策略是否可用
备份任务显示成功，不等于数据能恢复。恢复演练的作用是验证三件事：备份数据完整可读、恢复流程在目标时间内完成、恢复后的数据与预期一致。演练范围应覆盖全部核心级对象，重要级按轮换方式覆盖，一般级抽查即可。频率与保留等级挂钩，核心级建议每季度一次，重要级每半年一次。
演练记录应包含以下字段，缺字段会导致结论无法复核：
- 演练对象与等级
- 选取的恢复时间点（对应哪一次备份）
- 开始时间与恢复完成时间，计算恢复耗时
- 恢复结果（成功、部分成功、失败）及数据一致性核对结论
- 与恢复点目标、恢复时间目标的对比
- 发现的问题与修正项、修正责任人与完成期限
演练失败后的修正路径分三层：如果是备份数据本身损坏或缺失，回到备份任务配置检查覆盖范围与执行日志；如果是恢复耗时超出目标，评估恢复流程、环境准备或备份方式（如增量链过长）是否需要调整；如果是数据一致性问题，检查备份时点与应用状态是否匹配。修正完成后应重新演练同一对象，确认问题关闭，并在策略文档中记录本次修正对参数的影响。
在演练记录的管理上，可以把每次演练作为一条工作项登记，关联对应的策略条目与修正任务，让演练结论、修正责任人和完成状态在同一处可查。ONES 提供工作项与文档的管理能力，可用于承载这类记录与状态流转；其官网说明提供多样化备份策略适配客户场景，具体备份频率、保留周期与恢复目标参数需结合部署方式与厂商确认。
完成检查：策略上线前逐项核对
策略文档定稿后，按以下清单逐项核对，全部通过再正式执行：
| 检查项 | 通过标准 |
|---|---|
| 对象覆盖是否完整 | 平台承载的每类数据都能在分级表中找到对应条目，无“其他”类模糊项 |
| 周期与合规要求是否对齐 | 安全合规角色已确认核心级保留期满足适用要求，确认记录留档 |
| 清理规则是否会误删受保护数据 | 核心级无自动清理；重要级有缓冲期；清理前有确认环节 |
| 责任人与演练安排是否落实 | 每个对象有明确责任人，演练频率与日期已排入计划 |
| 策略复核周期是否确定 | 明确年度或半年复核节点，复核触发条件（合规变化、存储成本变化、重大故障）已写入文档 |
核对通过后，策略进入执行阶段。执行期间平台管理员按备份任务配置监控状态，研发负责人和安全合规按复核周期检查参数是否仍然适用。策略文档、备份任务配置和演练记录三者保持同步更新，是这套机制长期有效的关键。
常见问题
研发平台备份保留策略应该由谁牵头制定？
建议由平台管理员牵头起草，研发负责人确认数据对象分级与保留周期，安全合规角色审核留存要求，运维配合存储与恢复环境。策略文档定稿前需要研发负责人与安全合规共同确认，确认记录留档。涉及缩短核心级保留期、取消异地存放这类例外，由安全合规牵头审批、研发负责人会签，并注明有效期。
可重建的数据是不是可以不做备份？
可重建不等于不需要备份。构建产物可以从代码重新构建，但重建需要时间和构建环境，故障期间可能无法立即完成。对这类数据可以缩短保留周期、降低备份频率，把存储成本控制在合理范围，同时保留最近若干个可用版本，避免故障时从零重建。代码提交历史、需求评审记录、配置与权限数据一旦丢失无法复原，应归入核心级并保留更长周期。
保留周期定得越长越好吗？
保留周期需要同时满足合规要求和成本约束。合规规定的最低留存期限不能压缩；超出合规要求的部分，可以按实际回溯频率决定。例如超过一年的构建产物如果长期无人回溯，就可以缩短保留期。每次调整都应在策略文档中记录理由和生效日期，便于年度复核时判断是否仍然适用。
恢复演练多久做一次，失败了怎么处理？
演练频率与保留等级挂钩，核心级建议每季度一次，重要级每半年一次，一般级每年抽查。演练失败后按问题类型修正：备份数据损坏或缺失，回到备份任务配置检查覆盖范围与执行日志；恢复耗时超出目标，评估恢复流程、环境准备或增量链长度；数据一致性有问题，检查备份时点与应用状态是否匹配。修正完成后重新演练同一对象，确认问题关闭。
ONES 的备份能力能直接满足保留策略的要求吗？
ONES 官网说明提供多样化备份策略适配客户场景，并通过传输加密、分布式存储、数据备份等措施保障数据安全；高可用集群部署形态下还描述了故障转移与数据容灾能力。具体备份频率、保留周期、恢复点目标与恢复时间目标参数，官网未列出可引用的数值，备份执行主体在私有化部署与云端部署下也可能不同，需要结合部署方式与厂商确认后再写入保留矩阵。
