3. 备份策略设计
备份策略设计的本质，是在“可恢复性、存储成本、备份耗时、对生产影响”四者之间找到可接受的平衡点。GitLab 的备份对象包括 PostgreSQL 数据库、Git 仓库数据、对象存储（如 LFS、附件、制品）、配置文件（/etc/gitlab）以及密钥文件（/etc/gitlab/gitlab-secrets.json）。这些对象的体积、变化速率和恢复优先级并不相同，因此策略设计不能只回答“多久备份一次”，而要回答“哪些数据用什么方式、以什么频率、保留多久、在什么时间窗口内完成”。
全量备份与增量备份的取舍
GitLab 官方提供的 gitlab-backup create 命令生成的是全量备份：每次执行都会把数据库、仓库和对象存储打包成一个归档。它的优点是恢复路径简单、依赖少、完整性容易验证；缺点是耗时和占用空间随数据量线性增长。对于 100 GB 级别的实例，一次全量备份在中等磁盘性能下可能需要 30～90 分钟，且会明显消耗 CPU、磁盘 IO 和网络带宽。
GitLab 本身没有原生的“块级增量备份”命令，增量能力通常来自底层存储或数据库层：PostgreSQL 使用 WAL 归档配合基础备份实现时间点恢复（PITR），文件系统或对象存储使用快照（如 LVM 快照、ZFS 快照、云盘快照）实现差异捕获。因此实际策略往往是“周期性全量 + 高频增量”的组合：
- 全量备份：每周一次，作为恢复基线，保证归档自包含。
- 增量/快照：每日或每小时一次，缩短 RPO，但必须与全量基线配套使用。
- WAL 归档：若要求 RPO 在分钟级，必须开启 PostgreSQL WAL 持续归档，否则只能恢复到最近一次全量或快照点。
备份频率与保留周期
频率由 RPO 决定，保留周期由合规要求、恢复场景和存储预算共同决定。一个常见的分层保留模型是：
| 层级 | 频率 | 保留周期 | 用途 |
|---|---|---|---|
| 小时级增量 | 每 1 小时 | 48 小时 | 误删、误改后的快速回退 |
| 每日全量 | 每天 1 次 | 14 天 | 日常恢复主力 |
| 每周全量 | 每周 1 次 | 8 周 | 跨周恢复、版本回溯 |
| 每月归档 | 每月 1 次 | 12 个月 | 合规审计、长期留存 |
保留周期不是越长越好。每多保留一份全量，就多一份存储和校验成本；同时旧备份的恢复演练频率低，容易在真正需要时才发现损坏。建议对超过 30 天的归档执行定期校验（如校验归档大小、解包测试、恢复演练），并明确“过期即删除”的自动化规则，避免备份目录无限膨胀。
RPO 与 RTO 目标设定
RPO（Recovery Point Objective）是“能容忍丢失多少数据”，对应备份频率；RTO（Recovery Time Objective）是“能容忍停机多久”，对应恢复速度。两者必须一起定义，否则会出现“备份很频繁但恢复要 8 小时”的错配。
以某研发团队为例，其 GitLab 实例约 200 GB，包含 3000 个仓库。业务方要求：代码丢失不超过 1 小时，故障后 4 小时内恢复服务。据此可推导：
- RPO = 1 小时 → 需要每小时一次增量或 WAL 归档，不能只做每日全量。
- RTO = 4 小时 → 恢复流程必须包含：准备目标机、安装同版本 GitLab、恢复 secrets 与配置、恢复数据库与仓库、启动并验证。按经验，200 GB 数据恢复约需 1.5～2.5 小时，加上环境准备，4 小时是可行但偏紧的目标。
RTO 的估算不能凭感觉，应通过恢复演练测量。建议记录每次演练的“开始时间、数据恢复完成时间、服务可用时间”，形成实际 RTO 基线。如果实测 RTO 超过目标，优先优化恢复流程（如预装同版本、使用更快的存储、并行恢复），而不是盲目增加备份频率。
备份窗口规划
备份窗口是备份任务允许运行的时间段，必须避开业务高峰和 GitLab 自身的维护任务（如 gitlab-rake gitlab:cleanup、容器镜像清理、日志轮转）。规划时考虑三点：
- 业务低峰：多数团队的低峰在凌晨 1:00～5:00，此时推送、CI 任务最少。
- 任务时长：全量备份耗时必须小于窗口长度，并预留 20% 余量。若全量需 90 分钟，窗口至少 2 小时。
- 任务错峰：全量、增量、WAL 归档、对象存储同步不要同时启动，避免 IO 争抢导致全部超时。
下面这张图展示了一个典型的备份策略在时间轴上的排布关系，以及 RPO/RTO 与备份频率、恢复流程之间的对应逻辑：
从图中可以看出，RPO 由增量/WAL 的频率决定，RTO 由恢复流程各阶段耗时累加决定。两者不是同一个维度：提高备份频率能改善 RPO，但不会自动缩短 RTO；要缩短 RTO，必须优化恢复步骤、准备同版本环境、使用更快的存储，并定期演练。
策略落地建议
综合以上分析，一个可执行的 GitLab 备份策略应至少明确以下内容：备份对象清单（数据库、仓库、对象存储、配置、secrets）、全量与增量的组合方式、各层保留周期、RPO 与 RTO 目标值、备份窗口起止时间、失败告警方式、恢复演练频率。建议将策略写入运维文档，并在每次架构变更（如扩容、迁移对象存储）后重新评估，因为数据量和恢复路径的变化会直接影响 RPO 与 RTO 的达成情况。