研发平台备份计划的约束主要来自四个方面：数据对象与一致性要求、时间与容量窗口、恢复目标、合规与权限。代码仓库、工作项、文档附件、配置与权限关系的可恢复粒度各不相同，RPO与RTO又必须由业务影响推导，因此备份计划不能只写“定期全量备份”。本文按盘点、定目标、排计划、定角色、写示例、上线检查的顺序，给出可执行的制定步骤与交付物；涉及工作项、文档与权限记录的承载时，可自然衔接ONES的对应能力。
要点总览（TL;DR）
- 备份范围从数据对象盘点开始：代码仓库、工作项记录、文档附件、配置与权限关系通常不可重建，构建产物多数可重建，按可重建性分级决定备份投入。
- RPO与RTO必须由业务影响推导并书面确认：RPO决定备份频率，RTO决定恢复手段与演练强度，两者分别设定，不用“尽快恢复”笼统代替。
- 排期要处理全量与增量的组合、避开研发高峰与发布窗口、按数据分级确定保留代数，并为失败任务配置重试、告警与自动补备。
- 执行、范围确认与恢复授权三类职责分开，交付物固定为备份任务清单、监控告警记录、恢复申请单和演练报告。
- 计划上线前用清单验收，其中最关键的一项是完成至少一次真实恢复演练，记录实际耗时并与RTO比对。
先盘点：哪些数据对象决定备份范围与粒度
备份范围从数据对象清单开始，不从备份工具开始。研发平台的数据分散在代码托管、项目管理、文档协作、配置与权限等多个模块，各自的可重建性差别很大。盘点时要逐项记录对象名称、存储位置、是否可重建、期望恢复粒度和负责人，形成一份可评审的清单。
研发平台常见的数据对象可以归为五类：代码仓库与分支（含提交历史、标签、合并记录）、工作项与状态流转记录（需求、任务、缺陷及其变更历史）、文档与附件、配置项与权限关系（项目配置、角色授权、集成凭据）、流水线与构建产物。前四类通常不可重建或重建成本极高，构建产物多数可由代码与流水线配置重新生成。
按可重建性分级是控制成本的关键。不可重建的过程记录——代码提交历史、工作项流转记录、评审意见、附件——一旦丢失无法还原，应纳入常规备份并设定较短的RPO。可重建的产物可以只保留最近若干版本，甚至依赖重新构建，不必占用与核心记录同等的存储和保留代数。
恢复粒度需要在盘点阶段就写清楚，常见三档：单条记录（误删一个工作项或一份文档）、单个项目空间（某项目整体回滚）、整租户（平台级故障恢复）。粒度越细，对备份方式和恢复工具的要求越高，成本也越高。清单中应标注每个对象期望支持到哪一档，避免上线后才发现只能整库恢复。
| 数据对象 | 存储位置 | 可重建性 | 恢复粒度 | 负责人 |
|---|---|---|---|---|
| 代码仓库与分支 | 代码托管服务 | 不可重建 | 单仓库 / 整租户 | 代码平台负责人 |
| 工作项与状态流转记录 | 项目管理数据库 | 不可重建 | 单条记录 / 项目空间 | 项目管理负责人 |
| 文档与附件 | 文档服务与对象存储 | 不可重建 | 单篇 / 项目空间 | 文档管理员 |
| 配置项与权限关系 | 平台配置库 | 部分可重建 | 项目空间 / 整租户 | 平台运维 |
| 流水线与构建产物 | 流水线服务与制品库 | 可重建 | 按版本保留 | 构建平台负责人 |
盘点完成后，清单应经过各数据所有者确认，而不是由运维单方填写。确认动作本身也是责任划分：谁确认了对象范围和保留期限，后续范围遗漏或期限争议就有据可查。
定目标：RPO与RTO如何从业务影响推导
RPO指可容忍丢失多长时间的数据，决定备份频率；RTO指可容忍停机多久，决定恢复手段和演练强度。两者含义不同，常被混用：备份每小时执行一次，RPO约为1小时，但如果恢复一次整租户需要8小时，RTO就是8小时，与备份频率无关。计划中应分别设定，不能用一个“尽快恢复”笼统代替。
推导方法是从业务影响出发，而不是从技术便利出发。对每类对象问两个问题：这类数据丢失半天、一天、一周，业务分别受什么影响；平台不可用1小时、4小时、1天，哪些团队和交付节点会被卡住。答案由业务侧给出，运维负责把答案转成数值并评估实现成本。
按对象分级设定目标更现实。核心代码与工作项记录通常要求较短的RPO，因为提交历史和流转记录无法补录；一般文档可以放宽；可重建的构建产物可以只保留版本，不设严格RPO。RTO同样分层：核心协作功能优先恢复，报表、集成等辅助功能可以后置。
| 对象分级 | RPO参考 | RTO参考 | 对应备份频率 | 演练频率 |
|---|---|---|---|---|
| 核心代码与工作项记录 | 小时级 | 小时级 | 每日全量 + 高频增量 | 每季度 |
| 一般文档与附件 | 天级 | 天级 | 每日增量 | 每半年 |
| 可重建产物 | 不适用 | 按需重建 | 按版本保留 | 随核心演练验证 |
目标值必须形成书面确认记录，写明确认人、确认日期和依据的业务影响说明。运维单方拍定的频率在事故复盘时很难站住脚；业务确认过的目标，即使后续调整，也有清晰的变更依据。RPO/RTO确定后，备份频率、保留代数和演练频率都应与之对应，出现不一致时以目标为准调整执行安排。
排计划：备份周期、保留策略与容量窗口怎么定
排期把目标落成具体安排。全量与增量组合是常见做法：全量备份提供完整恢复基线，增量备份缩短RPO并降低日常负载。核心数据库类对象适合“周期全量 + 高频增量”，文档附件适合按变更增量，代码仓库可依赖自身的多副本与定期快照。选择组合方式时，同时考虑恢复路径——增量链越长，恢复耗时越长，RTO会被拉长。
执行时间窗口要避开研发高峰和发布窗口。多数团队的提交与流水线高峰在工作日下午，发布集中在固定时段，备份任务应错开这些区间，并与数据库维护窗口协调。跨地域副本的传输会占用带宽，需评估对日常访问的影响，必要时限制传输速率或安排在夜间。
保留代数按合规要求和恢复场景确定。常见做法是保留若干天日备、若干周周备、若干月月备，具体代数由数据分级和留存期限决定。容量估算可按“单次全量大小 × 全量代数 + 日均增量 × 增量保留天数”粗算，再预留增长余量；附件和制品库往往是容量增长最快的部分，应单独估算。
失败处理机制是排期的一部分。每个备份任务应配置失败重试次数、告警接收人和补备规则：重试仍失败时触发告警，并在下一个窗口自动补备；连续失败达到阈值时升级通知。没有补备机制的计划，一次失败就可能造成数天的数据缺口。
异地副本的必要性取决于RTO要求和机房风险。同城双副本能应对单机或单盘故障，异地副本用于应对机房级灾难，成本包括存储、带宽和运维复杂度。是否建设异地副本，应回到业务确认的RTO：如果机房级故障的恢复时间可以接受较长，异地副本可以降级为定期离线归档。
| 对象 | 方式 | 频率 | 时间窗口 | 保留代数 | 存储位置 |
|---|---|---|---|---|---|
| 代码仓库 | 快照 + 镜像副本 | 每日 | 凌晨 | 30天 | 本地 + 异地 |
| 工作项数据库 | 全量 + 增量 | 每日全量、每小时增量 | 凌晨全量、整点增量 | 日备30份、月备12份 | 本地 + 异地 |
| 文档与附件 | 增量同步 | 每日 | 夜间 | 30天 | 对象存储副本 |
角色与交付物：谁执行、谁校验、谁批准恢复
备份计划落地需要三类职责分开：执行与监控、范围与期限确认、恢复授权。平台运维负责备份任务的配置、执行和监控告警处置；数据所有者确认各自对象的备份范围和保留期限；安全与合规角色审核数据分级、加密方式和留存期限是否符合要求。恢复操作单独设审批，明确审批人和触发条件，避免误操作扩大故障。
恢复审批的触发条件应写具体：单条记录或单项目空间恢复由数据所有者申请、平台负责人审批；整租户恢复需业务负责人和安全角色共同确认。审批记录本身也是交付物，包含恢复范围、目标时间点、影响评估和回退方案。
各角色的交付物应固定下来，便于审计和交接：备份任务清单（对象、方式、频率、责任人）、监控告警记录、恢复申请单、演练报告。演练报告至少记录演练范围、参与角色、实际恢复耗时、发现的问题和整改项。这些记录在ONES中可借助工作项跟踪整改任务、用文档沉淀计划与报告、用权限设置控制恢复申请单的可见范围；ONES公开资料提到其通过数据备份等措施保障数据安全，并提供多样化备份策略适配客户场景，具体备份方式、频率与保留参数需在实施时结合部署形态与厂商确认。
| 角色 | 主要职责 | 交付物 |
|---|---|---|
| 平台运维 | 配置执行备份任务、监控告警、处置失败与补备 | 备份任务清单、监控告警记录 |
| 数据所有者 | 确认对象范围、恢复粒度与保留期限 | 对象清单确认记录 |
| 安全与合规 | 审核数据分级、加密与留存期限 | 合规审核意见 |
| 恢复审批人 | 审批恢复申请、确认影响与回退方案 | 恢复申请单 |
| 演练组织者 | 组织恢复演练、记录结果与整改项 | 演练报告 |
示例：一份可执行的季度备份计划片段
以下片段选取代码仓库、工作项记录、文档附件三类对象，示范如何把前面的约束写成可执行条目。示例为演示情景，数值需按团队实际业务影响调整。
代码仓库条目。输入：仓库清单与RPO目标（小时级）。动作：每日凌晨执行仓库快照，同步镜像到异地存储，保留30天。输出：备份任务执行记录与校验结果（快照可挂载、提交历史完整）。完成标志：当日任务成功且校验通过，失败时已触发告警并在下一窗口补备。
工作项记录条目。输入：项目空间清单与RPO目标（小时级）、RTO目标（小时级）。动作：每日全量备份数据库，每小时增量，保留日备30份、月备12份。输出：备份记录、增量链完整性检查结果。完成标志：全量与增量均成功，抽样恢复单条工作项验证通过。
文档附件条目。输入：文档库清单与RPO目标（天级）。动作：每日夜间增量同步至对象存储副本，保留30天。输出：同步日志与抽样文件校验结果。完成标志：同步无遗漏，抽样附件可正常打开。
恢复演练安排。每季度组织一次，范围覆盖上述三类对象各一个样本：从备份恢复一个代码仓库到隔离环境、恢复一个项目空间的工作项数据、恢复一批文档附件。参与角色包括平台运维、数据所有者和演练组织者，安全角色观察。判定标准：实际恢复耗时不超过对应RTO，恢复后数据完整性与一致性校验通过，演练报告在五个工作日内完成并列出整改项。
片段按规模调整的方式：团队和项目空间较少时，可合并全量与增量窗口、降低演练频率至每半年；平台规模较大、项目空间众多时，应按项目空间分批备份、增加异地副本，并把演练拆分为单对象演练和整租户演练两类。调整后需重新确认RPO/RTO是否仍然成立。
完成检查：备份计划上线前要验证的清单
计划写完后，用一份清单逐项核对，确认可执行、可恢复、可审计。以下条目均可直接勾选，未通过项应在上线前整改。
- 范围检查：对象清单覆盖全部不可重建数据，每项都有负责人确认记录；可重建产物已明确标注不纳入常规备份的理由。
- 目标检查：每类对象的RPO/RTO有业务书面确认，备份频率与保留代数与目标一致，不存在目标与执行脱节的情况。
- 可恢复性检查：至少完成一次真实恢复演练，记录实际耗时、恢复范围和校验结果；演练发现的问题已转为整改任务并关闭。
- 运维检查：告警能送达值班人员，失败重试与补备机制经过模拟验证，保留策略由系统自动执行而非人工清理。
- 合规检查：数据分级、加密方式和留存期限有审核留档，恢复审批流程已发布并告知相关角色。
清单通过后，计划进入执行阶段，但仍需按季度复核：业务影响变化、平台规模增长或部署形态调整时，RPO/RTO和排期应同步修订。备份计划的有效性最终由恢复演练证明，而不是由备份任务的成功率单独证明。
常见问题
研发平台规模扩大后，原来的备份计划需要怎么调整？
规模扩大主要影响三处：备份窗口、恢复耗时和演练组织方式。项目空间和仓库数量增长后，单次全量备份可能超出夜间窗口，应按项目空间分批备份，或改为更频繁的增量加周期全量。增量链变长会拉长恢复耗时，需要重新核对RTO是否仍然成立。演练也应拆分：先做单对象恢复演练，再做整租户演练。调整完成后，RPO/RTO目标要重新经业务确认，不能沿用旧数值。
备份任务连续失败时，除了告警还应该做什么？
告警只是第一步。计划中应约定失败重试次数和补备规则：重试仍失败时在下一个窗口自动补备，连续失败达到阈值时升级通知到平台负责人。同时要评估数据缺口：从最后一次成功备份到当前的时间是否已超出该对象的RPO，若已超出，应优先安排人工补备并记录缺口区间。每次失败与补备都应留痕，作为季度复核排期是否合理的依据。
恢复演练需要做到什么程度才算有效？
有效演练要满足三点：使用真实备份数据而非模拟数据；在隔离环境中实际执行恢复，记录从发起到可用的完整耗时；对恢复后的数据做完整性与一致性校验，例如代码仓库提交历史是否完整、工作项状态流转是否连续、附件能否正常打开。演练范围至少覆盖每类不可重建对象各一个样本。演练报告应列出实际耗时与对应RTO的比对结果，并把发现的问题转为整改任务跟踪关闭。
私有化部署时，备份执行和监控由谁负责？
这取决于部署合同中的责任划分，需要在实施阶段与厂商明确写清。常见分工是客户运维团队负责备份任务的执行、监控与恢复操作，厂商提供备份方式建议和技术支持；也有厂商承担部分平台层备份的情况。无论哪种分工，数据所有者确认对象范围与保留期限、恢复操作设审批这两项职责都应留在客户侧。责任边界未写清时，事故复盘容易出现推诿，建议在计划文档中单列一节说明。
可重建的构建产物是否完全不需要备份？
可以不纳入常规备份，但要有前提：代码仓库、流水线配置和依赖源都完好，且重新构建的耗时在可接受范围内。如果某次发布依赖的制品需要长期留存以备审计或回滚，应按版本保留策略单独保存，而不是依赖随时重建。计划中应明确标注这类对象不纳入常规备份的理由，避免上线检查时被当作范围遗漏。
