GitLab的备份和恢复策略有哪些

GitLab 备份与恢复策略

一 核心策略与范围

先来聊聊备份的核心。GitLab 官方内置的备份工具非常方便，它能生成一个包含应用数据的单归档文件，默认格式是 tar。这个文件就像是一个“数据快照”，囊括了几乎所有核心资产：

• 数据库（PostgreSQL）：你的项目、用户、Issue 等元数据都在这里。
• 仓库（Repositories）：所有代码库的完整历史。
• 附件（Uploads）：用户上传的文件。
• CI/CD 作业产物（Artifacts）：流水线生成的包、报告等。
• LFS 对象、容器镜像仓库（Registry）、Pages 站点、构建日志（Builds）等。

备份文件默认会放在 /var/opt/gitlab/backups 目录下，文件名遵循 [TIMESTAMP]_gitlab_backup.tar 这样的格式，一目了然。

但是，这里有个关键点必须注意：这个备份并非“全能”。它不包含以下内容：

• /etc/gitlab 目录下的配置文件（如 gitlab.rb）。
• TLS 证书和 SSH 主机密钥。
• Redis 和 Sidekiq 的运行时数据（这些通常是临时或缓存数据）。
• 如果你使用了 PgBouncer 这类连接池，备份时还需要额外参数。

所以，要想实现真正意义上的“完整可恢复”，必须将配置文件和密钥单独备份。这就像是保管箱的钥匙和箱体本身，缺一不可。

二 备份策略与配置

知道了备份什么，接下来就是怎么执行和优化了。

备份命令与版本

• Omnibus 安装（主流方式）：直接使用 gitlab-backup create 命令（GitLab 12.1+ 版本）。如果是更早的版本，命令是 gitlab-rake gitlab:backup:create。
• 源码安装：命令稍长一些：bundle exec rake gitlab:backup:create RAILS_ENV=production。
• Docker 部署：需要在容器内执行：docker exec -t gitlab-backup create。

定时与保留

手动备份显然不现实，自动化才是正道。通过 Crontab 设置定时任务是最常见的做法。

• 定时任务示例：下面这行配置表示每天凌晨 2 点执行备份，并且抑制非必要输出（CRON=1 的作用）。

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1

• 本地保留策略：备份文件不能无限堆积。可以在主配置文件 /etc/gitlab/gitlab.rb 中设置保留时间：

gitlab_rails[‘backup_keep_time’] = 604800 # 单位是秒，这里表示保留7天

这个时间可以根据你的磁盘空间和合规要求灵活调整。

并行与性能

如果仓库数量庞大，串行备份可能会非常慢。这时候可以调整并发度来提速：

• GITLAB_BACKUP_MAX_CONCURRENCY=4：同时备份 4 个项目（默认是 1）。
• GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY=1：针对不同存储后端的并发（通常保持默认即可）。

适当调高并发数，备份效率会有显著提升。

高级选项

备份命令还提供了一些高级开关，用于特殊场景：

• 跳过部分数据：例如 SKIP=db,uploads。这在你已经使用外部数据库（如 RDS）或对象存储（如 S3）来托管某些数据时非常有用，可以避免重复备份。
• 仅生成目录不打包：使用 SKIP=tar 参数。这会在备份目录中生成原始文件结构，方便你直接用 rsync 等工具同步到别处。
• 归档文件权限：通过 gitlab_rails[‘backup_archive_permissions’] = 0644 可以控制生成的 tar 包权限，确保安全。

三 恢复策略与步骤

备份的终极目的是为了恢复。恢复操作比备份更需谨慎，一步错可能导致数据不一致。

前提条件

• 版本一致：这是铁律。恢复目标环境的 GitLab 版本必须与创建备份时的版本完全一致。比如备份来自 12.10.5，就必须先恢复到 12.10.5，事后再升级。
• 机密文件：备份文件里不包含 /etc/gitlab/gitlab-secrets.json。这个文件至关重要，它保存了数据库加密密钥、CI/CD 变量、双因素认证密钥等。恢复前必须先把它放到正确位置。同样建议备份 /etc/gitlab/gitlab.rb 和 TLS/SSH 相关文件，否则恢复后可能出现安全告警或功能异常。

标准流程（以 Omnibus 安装为例）

1. 放置备份文件：将备份的 .tar 文件放到 /var/opt/gitlab/backups（或你自定义的备份目录）。
2. 停止写入服务：为了数据一致性，建议先停止接收新请求的服务：
   • gitlab-ctl stop unicorn (或 puma)
   • gitlab-ctl stop sidekiq
3. 执行恢复命令：关键点来了，命令中只需要指定时间戳前缀，不要包含 “_gitlab_backup.tar” 后缀。

   gitlab-backup restore BACKUP=1597812374_2020_08_19_12.10.5

   如果希望非交互式执行（不提示确认），可以加上 force=yes 参数。
4. 启动服务：恢复完成后，启动所有服务。

   gitlab-ctl start

5. 全面验证：通过 Web 界面登录，仔细检查项目、用户、CI Runner、Pages、LFS、容器仓库等是否都已完整还原。

Docker 场景

在 Docker 环境下，思路类似：先将备份文件通过卷挂载的方式放入容器内的相同路径，然后在容器内执行恢复命令：

docker exec -t  gitlab-backup restore BACKUP= [force=yes]

常见注意点

• 如果恢复时报错找不到文件，第一反应就是检查 BACKUP 参数的值是否正确，确保只用了时间戳前缀。
• 使用 PgBouncer 等数据库连接池时，备份命令需要添加相应参数。在多节点部署中，备份操作应该在运行 Puma 和 Sidekiq 的主应用节点上执行。

四 高可用与迁移实践

对于生产环境，本地备份只是第一道防线。

• 异地与云存储：强烈建议将备份归档同步到异地机房或云对象存储（如 AWS S3、阿里云 OSS）。这实现了地理级别的冗余，能应对机房级灾难。保留策略可以分层设计：本地保留 7 天用于快速恢复，异地保留 90 天、半年甚至永久，具体取决于合规要求和成本考量。
• 远程复制脚本思路：一个经典的实践是，在本地备份完成后，通过 scp 或 rsync 脚本，自动将新生成的 .tar 文件推送到远程备份服务器。远程服务器则设置脚本，按保留策略自动清理旧文件，形成“本地缓存+异地归档”的双层保护。
• 迁移即恢复：将 GitLab 从一个服务器迁移到另一个，本质上就是一次恢复操作。在新环境部署相同版本的 GitLab，先恢复 gitlab-secrets.json 和 gitlab.rb 配置文件，然后按照上述恢复流程导入备份归档。彻底验证所有功能正常后，再进行版本升级或切换生产流量。

五 验证与演练及关键注意事项

最后这部分，往往是决定备份方案成败的关键。

• 定期恢复演练：备份文件是否能恢复，不试永远不知道。建议制定季度或半年的演练计划，在隔离环境中执行一次完整的全量恢复。这不仅是为了验证数据完整性（RPO），更是为了测算恢复所需时间（RTO），并据此更新你的应急预案和操作文档。
• 版本与兼容性：再次强调，备份与恢复的版本必须一致。计划跨版本迁移？正确的步骤是：先在目标环境安装旧版本，恢复备份，验证无误后，再按照官方指南升级到新版本。
• 不包含与特殊组件：心里要始终有张清单，知道备份不包含什么：Redis/Sidekiq 队列、配置文件、TLS/SSH 密钥等。如果架构中使用了 PgBouncer、Patroni（PostgreSQL 高可用方案）等组件，务必查阅官方文档，遵循其特定的备份注意事项。
• 并发与锁：对于较老的 GitLab 版本（例如 15.5.0 之前），备份命令不会检查是否已有备份任务正在运行。如果并发执行，可能导致数据不一致或备份失败。因此，在自动化脚本中，建议做好任务串行化控制，避免撞车。

说到底，一个健壮的备份恢复体系，不仅仅是技术命令的堆砌，更是结合了清晰策略、定期演练和严谨流程的系统工程。把上述每一步都落到实处，你的代码资产才能真正高枕无忧。