研发平台承载代码、需求、缺陷、文档、流水线和账号配置，一旦误删或存储故障，损失往往超出单个项目。备份计划要回答四件事：哪些数据必须备份、多久备一次、谁能恢复、如何验证备份可用。计划落地的标志是每个关键数据对象都有负责人、备份频率、保留时长和最近一次恢复验证记录。
要点总览（TL;DR）
- 备份范围从数据对象盘点开始，覆盖代码仓库、工作项、附件、知识文档、流水线、账号配置和密钥七类对象，并按可重建性、丢失影响和恢复时限分级。
- 备份频率由数据变更速度和可接受丢失量决定，保留周期由合规要求和恢复场景决定，两者分别论证，核心对象同时保留本地与异地副本。
- 计划要落到具体责任人：平台管理员负责执行与巡检，数据所有者确认范围，安全负责人审批密钥备份与恢复授权，失败告警有明确的升级路径。
- 备份是否可用只能靠恢复演练证明，演练覆盖单对象误删、整库故障和配置丢失，验收看恢复时长、数据完整性和业务可用性。
- 计划可执行的标志是每个关键数据对象都有负责人、备份频率、保留时长和最近一次恢复验证记录，并约定复审周期与即时更新条件。
先盘清研发平台里哪些数据必须备份
备份范围从数据对象盘点开始。研发平台的数据分散在代码托管、工作项、文件存储、文档库、流水线、权限配置和密钥管理等多个位置，只备份主数据库容易漏掉附件、构建产物和凭证。盘点时按对象逐项登记来源系统、存储位置和负责人，形成一份可维护的清单。
常见的数据对象可以分为七类：
- 代码仓库：包括提交历史、分支、标签和合并记录，通常由代码托管系统独立存储。
- 工作项数据：需求、任务、缺陷、测试用例及其状态流转、评论和附件关联。
- 附件与文件：工作项附件、测试报告、设计稿、构建产物和发布包。
- 知识文档：产品文档、技术方案、会议记录和页面历史版本。
- 流水线与构建产物：流水线定义、运行记录、制品仓库中的镜像和包。
- 账号权限与配置：用户、角色、项目权限、系统参数、集成配置和Webhook。
- 密钥与凭证：访问令牌、证书、第三方集成密钥和数据库连接凭据。
盘点完成后按三个角度分级。可重建性判断数据能否从其他来源重新生成，例如构建产物通常可从代码重新构建，而代码提交历史无法重建。丢失影响判断数据缺失对业务、合规和客户的影响范围。恢复时限决定这类数据允许中断多久，直接影响备份频率和存放方式。三个角度综合后给出等级，例如核心、重要、一般。
盘点表的推荐结构如下，每行对应一个数据对象：
| 数据对象 | 来源系统 | 存储位置 | 可重建性 | 影响等级 | 负责人 |
|---|---|---|---|---|---|
| 代码仓库 | 代码托管 | 独立存储节点 | 不可重建 | 核心 | 代码平台管理员 |
| 工作项数据 | 项目管理 | 主数据库 | 不可重建 | 核心 | 平台管理员 |
| 附件与文件 | 文件服务 | 对象存储 | 部分可重建 | 重要 | 平台管理员 |
| 知识文档 | 文档库 | 数据库与对象存储 | 不可重建 | 重要 | 文档负责人 |
| 流水线定义与记录 | CI/CD | 数据库 | 部分可重建 | 重要 | 构建平台负责人 |
| 账号权限与配置 | 平台各模块 | 数据库与配置文件 | 可重建但成本高 | 核心 | 平台管理员 |
| 密钥与凭证 | 密钥管理 | 加密存储 | 部分可重建 | 核心 | 安全负责人 |
这张表的完成标志是：每个对象都有明确负责人，没有“待确认”的存储位置，核心与重要对象全部标注了可重建性判断。密钥类对象的备份方式需要单独处理，通常采用加密后离线保存，与普通数据备份分开管理。
确定备份方式、频率与保留周期
分级结果直接决定备份参数。核心对象需要更高频率、更长保留和异地副本，一般对象可以降低频率、缩短保留。全量备份与增量备份搭配使用：全量备份提供完整恢复基线，增量备份缩短单次备份耗时和存储占用。常见做法是每周一次全量、每日一次增量，具体节奏按数据变更速度调整。
频率由两个因素决定：数据变更速度和可接受丢失量。工作项数据每天大量变更，可接受丢失量若为一天，就按日备份；代码仓库以推送为单位变更，可结合代码托管自身的镜像或快照机制按小时级同步。保留周期由合规要求和恢复场景决定，例如需要追溯三个月前的配置状态，保留周期就不能短于三个月。频率和保留周期分别论证，避免用同一个数字套所有对象。
存放位置要避免单点失效。本地备份恢复速度快，适合日常误删；异地或离线副本应对机房级故障和勒索软件，两者组合使用。离线副本定期与生产环境断开，降低被同时破坏的风险。备份窗口安排在对研发活动干扰最小的时段，大规模全量备份可放在夜间或周末，增量备份选择变更低谷期，并在计划中写明窗口时长和对流水线、代码推送的影响范围。
| 对象 | 方式 | 频率 | 保留时长 | 存放位置 | 备份窗口 |
|---|---|---|---|---|---|
| 代码仓库 | 全量镜像加增量同步 | 每日增量，每周全量 | 90天 | 本地加异地 | 每日凌晨 |
| 工作项数据 | 全量加增量 | 每日一次 | 180天 | 本地加异地 | 每日凌晨 |
| 附件与文件 | 增量同步 | 每日一次 | 90天 | 对象存储跨区域 | 每日凌晨 |
| 知识文档 | 全量加增量 | 每日一次 | 180天 | 本地加异地 | 每日凌晨 |
| 账号权限与配置 | 全量导出 | 每周一次，变更前手动 | 一年 | 本地加离线 | 周末 |
| 密钥与凭证 | 加密全量 | 变更时触发 | 按合规要求 | 离线加密介质 | 变更窗口 |
参数表完成后，逐项核对每个核心对象是否同时具备本地与异地副本，保留时长是否覆盖至少一次完整恢复场景。参数不是一次定死，数据量增长或合规要求变化时应重新评估。
角色分工与备份执行流程
备份计划需要明确四类角色。平台管理员负责备份任务的配置、日常巡检和失败处理；运维人员负责存储、网络和备份介质的维护；数据所有者通常是各模块负责人，确认自己领域的数据是否纳入备份、保留多久；安全负责人审批密钥类数据的备份方式与访问权限，并参与恢复授权。角色可以兼任，但每项职责要有具体姓名，避免出现无人认领的对象。
执行流程从触发开始。定时任务按策略表自动触发，变更前手动备份由变更发起人提出、平台管理员执行。每次备份完成后自动校验备份文件完整性，失败时触发告警。告警路径要写清楚：一级告警通知平台管理员，两小时内未处理升级至运维负责人，影响核心对象的失败同步通知数据所有者。告警渠道、值班安排和升级时限都写入计划，避免告警发出后无人响应。
备份记录与凭证的保存要求包括：每次备份的时间、对象、方式、结果、文件大小和存放位置；备份文件的校验值；执行人和复核人。记录保留时间不短于对应备份的保留周期，便于恢复时追溯。变更前手动备份的触发条件建议包括：数据库结构变更、权限模型调整、大规模数据导入、平台版本升级和密钥轮换。这些操作一旦出错影响面大，手动备份提供快速回退点。
在平台侧，备份任务、告警处理和变更前备份申请可以作为工作项统一跟踪。ONES 提供多样化备份策略适配客户场景，并通过数据备份、分布式存储和实时监控告警等措施保障数据安全；将备份执行记录、失败告警和恢复申请纳入同一工作项流程，可以让责任人和处理状态在平台内可见，减少靠邮件和聊天工具传递造成的遗漏。
恢复演练怎么组织与验收
备份是否可用只能通过恢复演练证明。演练场景至少覆盖三类：单对象误删，例如误删一个工作项或一份文档；整库故障，例如主数据库不可用；配置丢失，例如权限配置或集成配置被覆盖。每类场景对应不同的恢复路径和验收重点，计划中应写明本年度覆盖哪些场景、由谁组织。
恢复步骤按顺序执行：由数据所有者或发现人提交恢复申请，说明对象、时间点和影响范围；平台管理员与安全负责人审批，核心数据恢复需双人确认；在隔离环境中执行恢复，避免覆盖生产数据；恢复完成后进行数据校验，比对记录数量、关键字段和附件完整性；校验通过后切换或回填生产环境，并通知相关方。隔离环境恢复是关键环节，直接在生产环境操作会放大风险。
验收标准围绕三个指标：恢复时长是否在恢复时限内，数据完整性是否达到约定标准，业务可用性是否恢复，例如用户能正常登录、工作项能正常打开、流水线能正常触发。验收结论分为通过、有条件通过和不通过，不通过时记录原因并安排复测。演练记录表包含演练时间、场景、参与人、实际恢复时长、发现的问题和整改责任人。问题闭环要求每个问题有整改措施和完成时间，下一次演练时复核。
一个研发团队的备份计划示例
以下为演示情景，用于说明三张表如何组合成一份可执行计划。某研发团队约五十人，使用一套研发平台管理代码、需求、缺陷、文档和流水线，平台部署在自有服务器上。
盘点与分级结果：代码仓库、工作项数据、账号权限与配置、密钥与凭证定为核心；附件与文件、知识文档、流水线定义与记录定为重要；构建产物定为一般，可从代码重新构建。每个对象指定了负责人，代码仓库由代码平台管理员负责，工作项和附件由平台管理员负责，文档由文档负责人负责，密钥由安全负责人负责。
对应的策略参数：代码仓库每日增量、每周全量，保留90天，本地加异地存放；工作项数据每日全量加增量，保留180天；附件每日增量同步至跨区域对象存储；知识文档每日备份，保留180天；账号权限每周全量导出，变更前手动备份，保留一年；密钥变更时加密备份至离线介质。全量备份安排在凌晨，增量备份在变更低谷期执行。
一次误删恢复演练的过程：测试人员在测试项目误删一个包含附件的工作项，十分钟后发现。数据所有者提交恢复申请，平台管理员审批后在隔离环境恢复前一日备份，比对工作项字段和附件数量一致，实际恢复耗时四十分钟，在约定的两小时恢复时限内。演练发现附件恢复需要单独执行同步任务，原计划未写明该步骤，整改措施是补充恢复操作手册并安排复测。结论为有条件通过。
计划评审与更新节奏：计划每半年评审一次，评审内容包括对象清单是否新增系统、保留周期是否满足合规要求、上次演练问题是否闭环。触发即时更新的条件包括平台版本升级、新增数据对象、组织架构调整和发生真实数据事件。评审记录与演练记录一并归档。
上线前的完成检查清单
计划进入执行前，用以下清单逐项核对。每项给出通过标准和责任人，全部通过才视为可执行状态。
| 检查项 | 通过标准 | 责任人 |
|---|---|---|
| 数据对象全覆盖 | 盘点表覆盖平台全部数据对象，每项有负责人，无待确认项 | 平台管理员 |
| 策略参数完整 | 每类对象都有备份方式、频率、保留周期和存放位置 | 平台管理员 |
| 副本与窗口确认 | 核心对象具备本地与异地副本，备份窗口已通知研发团队 | 运维负责人 |
| 告警可触达 | 告警渠道、值班安排和升级路径经过一次模拟验证 | 运维负责人 |
| 恢复演练完成 | 至少完成一次演练，覆盖一个核心对象，记录与结论已归档 | 数据所有者 |
| 问题闭环 | 演练发现的问题均有整改措施和完成时间 | 平台管理员 |
| 复审机制约定 | 写明复审周期和即时更新触发条件 | 平台负责人 |
清单核对完成后，计划文档、盘点表、策略参数表、职责表、演练记录和检查结果合并归档，作为后续复审的基线。真实数据事件发生后，无论是否造成损失，都应回看清单中相关项是否需要调整。
常见问题
研发平台已经做了高可用集群，还需要单独制定备份计划吗？
需要，两者解决的问题不同。高可用架构处理的是节点或组件故障时的服务连续性，例如故障转移和零停机升级；备份处理的是数据被误删、被覆盖或遭到破坏后能否回到某个时间点。误删一个工作项、错误执行一次数据清理，高可用机制无法把数据找回来。
因此高可用部署可以作为恢复时限的有利条件，但不能替代备份。计划中仍要按数据对象确定备份频率和保留周期，并保留至少一次恢复演练记录。
密钥和凭证类数据怎么备份，能和普通数据放在一起吗？
建议分开管理。密钥与凭证的敏感度高于普通业务数据，备份时先加密，再存放到离线或受控介质，访问权限限制在安全负责人和少数授权人员。与普通数据备份混放会扩大泄露面，恢复时也不便于单独审批。
密钥备份的触发条件通常是变更时，例如轮换、新增集成或证书更新。每次备份记录执行人、校验值和存放位置，恢复时由安全负责人审批并双人确认。
团队规模小、没有专职运维，备份计划可以简化到什么程度？
可以合并角色，但不能省略职责。小团队常见做法是平台管理员兼任运维和数据所有者确认人，安全审批由团队负责人承担，关键是每项职责落到具体姓名，而不是停留在岗位名称。
可以简化的部分包括：减少备份对象分类层级、把全量备份集中在周末、用平台告警替代独立监控系统。不建议简化的是恢复演练和记录留存，哪怕一年只做一次单对象误删恢复，也能暴露恢复步骤中的遗漏。
恢复演练一定要在隔离环境做吗，直接在生产环境验证不是更真实？
建议在隔离环境执行恢复和校验，确认数据完整后再决定是否回填生产。直接在生产环境恢复会带来二次覆盖风险：恢复的时间点选错，可能把之后产生的正常数据一并覆盖。
隔离环境演练同样能验证备份文件可用性、恢复步骤是否完整、实际耗时是否在恢复时限内。只有在确认生产数据已不可用、且经过审批的情况下，才直接在生产环境执行恢复，并全程留痕。
备份计划制定后，什么情况下需要立即更新而不是等定期评审？
常见触发条件包括：平台版本升级、新增数据对象或接入新系统、组织架构和负责人调整、合规要求变化，以及发生真实数据事件。真实事件无论是否造成损失，都应回看相关检查项是否需要调整。
定期评审建议每半年一次，重点核对对象清单是否覆盖新增系统、保留周期是否仍满足要求、上次演练发现的问题是否闭环。评审记录与演练记录一并归档，作为下一次评审的基线。
