当前位置：首页 > news >正文

GitLab 17.8 备份秘籍：快速获取纯 Git 仓库与核心配置

news 来源：原创 2025/6/24 14:12:21

大家好！今天，我们来聊聊运维和开发中一个至关重要的话题：数据备份。特别是对于使用 GitLab 这样的核心代码托管平台，一份可靠的备份策略是保障业务连续性、应对突发状况（比如误操作、硬件故障甚至安全事件）的最后一道防线。

有同学可能会问，我希望备份 GitLab 仓库，不仅仅是文件内容，最好能是纯净的 Git 仓库格式，方便迁移或在标准 Git 环境下使用，同时还想保留 GitLab 里那些重要的配置，比如 CI/CD 设置、用户权限等。在 GitLab 17.8 版本中，我们有哪些方法可以快速高效地实现这个目标呢？别急，这就为您揭晓。在这里插入图片描述

为什么需要备份成纯 Git 仓库？

在深入方法之前，我们先思考一下为什么会有这种需求。GitLab 提供的全量备份固然强大，包含了数据库、仓库、上传文件等等一切，但在某些场景下，我们可能只需要仓库本身，并且希望它是最“原始”的 Git 格式：

便捷迁移： 将仓库迁移到另一个 Git 平台（如 GitHub、自建 Gitea）或另一个 GitLab 实例时，纯 Git 仓库通常是最简单、最不容易出错的方式。
标准工具兼容性： 使用标准的 Git 命令或工具进行检查、分析或恢复时，纯 Git 仓库更加友好。
快速访问与恢复： 对于只需要恢复代码仓库本身的情况，直接操作纯 Git 仓库比从复杂的全量备份中提取要快得多。

当然，需要强调的是，纯 Git 仓库备份不包含 GitLab 专有的元数据，比如 Issue、Merge Request、Wiki、CI/CD Pipline 历史、用户评论、项目设置等等。如果我们的目标是灾难恢复或完整的 GitLab 实例迁移，我们需要结合其他方法。

方法一：利用 `git clone --mirror` 快速获取纯 Git 仓库

这是获取纯 Git 仓库最直接、最“暴力”的方法。git clone --mirror 命令会创建一个远程仓库的本地镜像，它会复制所有的 refs (分支、标签等)，但不会创建工作目录。这意味着我们得到的是一个裸仓库（bare repository），非常适合作为备份使用。

操作步骤：

获取仓库地址： 在 GitLab 中找到我们想要备份的项目的仓库地址（通常是 HTTP 或 SSH 地址）。
执行克隆命令： 在我们的备份服务器或本地机器上执行以下命令：
```
git clone --mirror <GitLab 仓库地址> /path/to/your/backup/repo.git
```
- <GitLab 仓库地址> 可以是 HTTP(S) 或 SSH 地址。如果是私有仓库，HTTP(S) 地址通常需要提供用户名和密码或个人访问令牌，SSH 地址需要配置好 SSH 密钥。
- /path/to/your/backup/repo.git 是我们希望存储备份的本地路径。.git 后缀是裸仓库的惯例。

示例（使用 SSH）：

假设我们的 GitLab 服务器地址是 gitlab.yourcompany.com，我们的项目路径是 mygroup/myproject：

git clone --mirror git@gitlab.yourcompany.com:mygroup/myproject.git /backups/gitlab/mygroup/myproject.git

执行完成后，/backups/gitlab/mygroup/myproject.git 目录下就会有一个完整的、纯净的 myproject 仓库镜像。

优点：

简单快捷，只需要标准的 Git 工具即可。
生成的备份就是标准的裸 Git 仓库，易于使用和迁移。

缺点：

不包含 GitLab 专有数据！ 这是最重要的一点。Issue、MRs、CI 配置、Wiki 等等都不会被备份。
每个仓库都需要单独执行命令。对于大量仓库，需要编写脚本自动化。

实用建议：

为了自动化，可以编写一个脚本，读取项目列表（可以通过 GitLab API 获取），然后循环执行 git clone --mirror。
定期运行此脚本，并增量更新备份（只需再次运行 git clone --mirror，它会自动抓取最新更改）。
将这些备份存储在异地或对象存储中，增加数据安全性。

方法二：利用 GitLab 内置的 Rake 任务进行应用备份（包含仓库和部分配置）

对于需要包含 GitLab 专有数据（包括仓库以及部分配置）的备份，GitLab 官方推荐的方式是使用其内置的 Rake 任务。这个方法生成的备份是一个压缩包，里面包含了数据库数据、仓库文件、上传文件等几乎所有重要的数据。虽然不是直接生成“纯 Git 仓库”文件，但它包含了仓库数据，并且是更全面的备份方案。

在 GitLab 17.8 中，备份命令是：

sudo gitlab-rake gitlab:backup:create

执行环境：

这个命令需要在 GitLab 服务器上以 root 用户或有足够权限的用户执行。

备份内容：

数据库（存储 Issue、MR、用户、权限、CI/CD 设置等大部分元数据）
Git 仓库（存储在指定的数据目录中）
上传文件
CI/CD Artifacts
LFS 对象
等等.

生成的备份文件通常是一个 .tar 压缩包，存放在 gitlab.rb 中配置的备份路径下（默认为 /var/opt/gitlab/backups）。

优点：

全面： 备份了几乎所有 GitLab 的重要数据，包括仓库和大部分 GitLab 专有元数据。
官方推荐： 这是 GitLab 官方支持和测试的备份方式，恢复过程相对可靠.
配置灵活（通过 gitlab.rb）。

缺点：

生成的备份文件是一个打包文件，不是直接可用的纯 Git 仓库。
恢复过程需要在相同版本的 GitLab 上进行（最好是完全相同的版本和类型，CE/EE）.
需要服务器的根权限。

实用建议：

自动化： 将此命令加入到 cron 任务中，实现每日或更频繁的自动备份。
配置备份路径： 修改 /etc/gitlab/gitlab.rb 文件中的 gitlab_rails['backup_path'] 设置，指定备份文件的存储位置，建议将其指向一个独立的磁盘或挂载点。
上传到远程存储： 配置 GitLab 将备份文件自动上传到 S3、Google Cloud Storage 等远程存储，提高备份的安全性（需要配置相关参数在 gitlab.rb 中）.
保留策略： 设置 gitlab_rails['backup_keep_time'] 来自动清理旧的备份文件，节省存储空间.

GitLab 专有配置的备份

GitLab 的核心配置主要存储在以下位置：

/etc/gitlab/gitlab.rb： 这是 GitLab Omnibus 安装的核心配置文件，几乎所有的实例级别配置都在这里。
/etc/gitlab/gitlab-secrets.json： 这个文件包含了加密密钥，非常重要！ 如果丢失，使用双因素认证（2FA）的用户将无法登录，并且 CI/CD 中的安全变量会丢失.
证书文件： 如果我们配置了 HTTPS，相关的证书文件（通常在 /etc/gitlab/ssl 或其他指定路径）也需要备份。

GitLab 的 Rake 任务备份包含了数据库中存储的大部分配置和元数据。但 /etc/gitlab/gitlab.rb 和 /etc/gitlab/gitlab-secrets.json 这两个文件不会被 Rake 任务备份到.tar 文件中。

如何备份这些关键配置？

GitLab 提供了专门的命令来备份这些配置文件：

sudo gitlab-ctl backup-etc

这个命令会将 /etc/gitlab 目录下的配置文件打包成一个 tar 压缩包，默认存放在 /etc/gitlab/config_backup/ 目录下.

实用建议：

定期执行： 将 sudo gitlab-ctl backup-etc 命令也加入到我们的自动化备份流程中。
异地存储： 将生成的配置备份文件（以及 Rake 任务生成的应用备份文件）存储到与 GitLab 服务器分离的位置，强烈建议是异地存储或云存储.
保管好 gitlab-secrets.json： 这个文件是恢复 GitLab 实例的关键，务必妥善保管.

结合使用：构建更健壮的备份策略

最理想的备份策略往往是结合使用不同的方法：

对于那些极其重要的、需要快速恢复或经常需要在标准 Git 环境下操作的仓库，可以考虑使用 git clone --mirror 进行额外的高频备份。
使用 GitLab 内置的 Rake 任务进行每日或定期的全量应用备份，这是灾难恢复的主要手段。
定期备份 /etc/gitlab 下的关键配置文件（使用 gitlab-ctl backup-etc）。
将所有备份文件（包括 Git 仓库镜像、应用备份压缩包、配置备份压缩包）都上传到安全可靠的异地存储或云存储服务。
定期测试恢复过程！ 这是最容易被忽视但又最重要的一环。只有真正演练过恢复，我们才能确保备份的有效性。

总结

在 GitLab 17.8 中，快速获取纯 Git 仓库最便捷的方式是使用 git clone --mirror 命令，但这只备份代码本身。要获取包含仓库和 GitLab 专有元数据的更全面的备份，应使用 sudo gitlab-rake gitlab:backup:create 命令。同时，不要忘记使用 sudo gitlab-ctl backup-etc 命令备份 /etc/gitlab 下的核心配置文件，特别是 gitlab-secrets.json 文件.

构建一个多层次、自动化的备份策略，并定期测试恢复过程，是确保我们的 GitLab 数据安全无虞的关键。希望这篇文章能帮助大家更好地管理 GitLab 备份！