适用范围与验证状态
本文用于 GitLab Self-Managed 的备份审阅和隔离恢复验收，验证等级为 PENDING。示例以 Linux package 安装为主；Docker、Helm、外置 PostgreSQL、PgBouncer 和多 Gitaly 存储必须按实际版本选择官方流程。这里没有执行任何备份、恢复、停止服务或生产切换，也不承诺某个数据规模能在固定时间内恢复。
优先区分三种需求：单个文件误删通常先检查 Git 历史；单项目数据缺失需要评估项目级恢复与实例级恢复的边界；实例损坏才进入完整灾备流程。不能仅因一次 clone 失败就在原实例运行全量恢复。实际执行流程见 GitLab 备份与隔离恢复演练。
先定义能够回答问题的恢复目标
恢复点目标描述可接受的数据丢失窗口，恢复时间目标描述恢复业务需要的时长。两者需要业务负责人确认，不能用“每天备份一次”代替。记录事故时间、最后可信写入时间、备份时间及统一时区，并列出仓库、合并请求、附件、LFS、制品、权限等具体对象。
建议先做一份小而确定的验收清单：选择受控项目及已知提交 SHA，记录一份 LFS 对象和附件的摘要、预期用户角色、一个应当拒绝访问的测试身份。样本只证明样本，不证明全库一致性；关键项目和抽样外数据的覆盖程度需要单独报告。清单保存在受限位置，不记录生产个人数据或秘密明文。
备份清单不能只看一个 tar 文件
应用备份、配置与 secrets、对象存储及其版本历史分别核对。Linux package 的应用备份不包含所有外部对象存储内容，也不能假定 Redis/Sidekiq 待执行任务和机器配置已纳入。对启用的功能逐项标注备份机制、时间、存放位置、保留期和恢复负责人；没有启用的功能标“未使用”，不是留空。GitLab 备份范围
如果使用 server-side repository 备份，还要确认外部仓库备份对象及必要增量链，不把应用归档误认为完全自包含。密钥材料按秘密管理流程与数据备份分开保管；保留对应配置版本，但不要把生产地址和存储引用未经审阅地原样应用到演练实例。Linux package 的配置备份有独立流程。配置备份说明
应用备份的一致性还要求后台任务没有待执行或运行项。应在批准的维护窗口内，按对应官方流程控制新任务进入并确认任务排空，保留状态证据，而不是为了满足清单擅自停止生产任务。既有备份没有这些证据时，应标明一致性缺口，不能只凭备份成功和文件摘要一致就宣布完整一致。后台任务备份边界
只读预检与证据可信度
以下是获准在 Linux package 主机执行的查询示例。环境信息可能包含内部地址，输出需要脱敏；不要直接贴进公开知识库。
sudo gitlab-rake gitlab:env:info
sudo gitlab-ctl status
sha256sum -- '<APPROVED_BACKUP_ARCHIVE>'版本信息用于核对源与目标，文件摘要用于识别传输损坏或拿错副本。摘要匹配不证明来源可信，更不证明数据库、仓库和对象桶在同一一致性窗口；应把摘要与备份任务日志、访问审计及业务写入时间一起判断。生产备份生成会消耗 I/O 和容量，另需维护窗口，不属于上面查询命令的隐含动作。
隔离恢复的四道停止条件
第一，目标必须是独立、可工作的空实例，版本与 CE/EE 类型与备份完全一致，恢复时不要顺便升级。第二，数据库、Gitaly 存储、对象桶和秘密材料映射已经复核，不能仍指向生产。第三，邮件、Webhook、Runner 取任务和其他出站自动化已被可靠隔离。第四，恢复权限、容量和可用备份副本均已确认。任一不满足都不应开始恢复。GitLab 恢复前提
“不同域名”并不能隔离出站行为。恢复的配置可能仍携带真实集成信息，后台任务也可能造成外部影响。演练网络应只允许必要的备份读路径和受控验收访问；保留原备份的只读副本，不让恢复任务写回备份源。界面可加醒目标识帮助人识别，但标识不能代替网络与数据隔离。
恢复失败时如何分流
- 版本或安装类型不符：重新准备匹配的空目标，不尝试绕过校验，也不改生产版本配合演练。
- 仓库恢复与数据库恢复结果不一致：查各子任务、存储名称和备份对象，不把能登录当作恢复成功。
- 附件或 LFS 缺失：回到对象存储/文件存储清单核对路径、版本及一致性时间，不通过从生产零散拷文件掩盖缺口。
- 加密字段无法使用：核对匹配的 secrets 与文件权限，按官方诊断流程检查，只记录问题数量或脱敏摘要，不导出秘密值。
- 超时或任务中断：先确认服务端执行状态和已完成阶段，保存日志。需要重试时重新准备经批准的空演练目标，避免多次覆盖导致证据不清。
这些分流是故障调查顺序，不是宣称唯一根因。每项结论至少记录“观察到什么、排除了什么、下一步验证什么”，不要只留下“恢复失败，再试一次”。
验收不是登录页返回成功
分别检查普通用户登录、权限边界、仓库读取、已知提交、分支或标签、Wiki、附件、LFS 和实际启用的制品能力。对一个应被拒绝的项目验证拒绝路径，防止把管理员能看见所有项目当作授权正确。恢复到新域名可能影响与源域绑定的身份验证设备，应在正式切换计划中单独评估，不在演练时降低认证要求来凑通过率。
仓库内容对照应以事前清单为准，不只统计项目数量。下载验收会消耗带宽并在客户端写入文件，使用受控目录和只读凭据，提前确认数据处理权限。整个演练不启用真实 Runner、部署密钥或发布任务，测试流水线也需与外部服务隔离。
回退、证据与交接
演练失败时保持隔离，保留目标状态、任务日志及备份引用，修复方案经审阅后在新目标重试。不要把恢复后的演练数据合回生产。若未来真的切入恢复实例，新写入的归属必须明确：切回旧 DNS 不会自动合并两端数据，也不能证明没有重复发布或重复通知。
交付记录包含审批号、源/目标标识、精确版本、备份 ID 与摘要、秘密材料引用、完整时间线、分项验收、数据缺口、实际恢复耗时及签核人。临时凭据和副本按保留策略回收；日志只保留必要证据，避免把备份包或内部用户信息当作知识附件公开。有关仓库日常权限和恢复责任见 代码仓库运行手册。