当你运行 备份命令 时，备份脚本会创建一个备份归档文件来存储你的极狐GitLab 数据。

为了创建归档文件，备份脚本会：

  1. 在执行增量备份时，提取之前的备份归档文件。
  2. 更新或生成备份归档文件。
  3. 运行所有备份子任务来：
  4. 将备份暂存区归档为一个 tar 文件。
  5. 如果已经配置，将新的备份归档上传到对象存储。
  6. 清理已归档的备份暂存目录文件。

备份数据库

为了备份数据库，db 子任务：

  1. 使用 pg_dump 创建一个 SQL 转储。
  2. 通过 gzip 管道处理 pg_dump 的输出，并创建一个压缩的 SQL 文件。
  3. 将文件保存到备份暂存目录。

备份 Git 仓库

为了备份 Git 仓库，repositories 子任务：

  1. 告知 gitaly-backup 需要备份哪些仓库。

  2. 运行 gitaly-backup 来：

    • 在 Gitaly 上调用一系列的远程过程调用 (RPC)。
    • 收集每个仓库的备份数据。
  3. 将收集的数据流传输到备份暂存目录中的目录结构中。

下图说明了这个过程：

%%{init: { "fontFamily": "GitLab Sans" }}%% sequenceDiagram box Backup host participant Repositories sub-task participant gitaly-backup end Repositories sub-task->>+gitaly-backup: List of repositories loop Each repository gitaly-backup->>+Gitaly: ListRefs request Gitaly->>-gitaly-backup: List of Git references gitaly-backup->>+Gitaly: CreateBundleFromRefList request Gitaly->>-gitaly-backup: Git bundle file gitaly-backup->>+Gitaly: GetCustomHooks request Gitaly->>-gitaly-backup: Custom hooks archive end gitaly-backup->>-Repositories sub-task: Success/failure

Gitaly 集群配置的存储与独立的 Gitaly 实例以相同的方式进行备份。

  • 当 Gitaly 集群接收到来自 gitaly-backup 的 RPC 调用时，它会重建自己的数据库。
    • 无需单独备份 Gitaly 集群数据库。
  • 每个仓库仅备份一次，无论复制因子如何，因为备份是通过 RPC 进行的。

服务器端备份

服务器端仓库备份是一种高效的备份 Git 仓库的方法。此方法的优点是：

  • 数据不会通过 RPC 从 Gitaly 传输。
  • 服务器端备份需要较少的网络传输。
  • 不需要在运行备份 Rake 任务的机器上存储磁盘。

为了在服务器端备份 Gitaly，repositories 子任务：

  1. 运行 gitaly-backup 为每个仓库进行单个 RPC 调用。
  2. 触发存储物理仓库的 Gitaly 节点将备份数据上传到对象存储。
  3. 使用 备份 ID 将存储在对象存储上的备份链接到创建的备份归档。

下图说明了这个过程：

%%{init: { "fontFamily": "GitLab Sans" }}%% sequenceDiagram box Backup host participant Repositories sub-task participant gitaly-backup end Repositories sub-task->>+gitaly-backup: List of repositories loop Each repository gitaly-backup->>+Gitaly: BackupRepository request Gitaly->>+Object-storage: Git references file Object-storage->>-Gitaly: Success/failure Gitaly->>+Object-storage: Git bundle file Object-storage->>-Gitaly: Success/failure Gitaly->>+Object-storage: Custom hooks archive Object-storage->>-Gitaly: Success/failure Gitaly->>+Object-storage: Backup manifest file Object-storage->>-Gitaly: Success/failure Gitaly->>-gitaly-backup: Success/failure end gitaly-backup->>-Repositories sub-task: Success/failure

备份文件

以下子任务备份文件：

  • uploads：附件
  • builds：CI/CD 作业输出日志
  • artifacts：CI/CD 作业产物
  • pages：页面内容
  • lfs：LFS 对象
  • terraform_state：Terraform 状态
  • registry：容器注册表镜像
  • packages：软件包
  • ci_secure_files：项目级别的密钥文件
  • external_diffs：合并请求差异（当存储在外部时）

每个子任务在一个任务特定的目录中识别一组文件，并：

  1. 使用 tar 工具创建识别文件的归档。
  2. 通过 gzip 压缩归档而不保存到磁盘。
  3. 将 tar 文件保存到备份暂存目录。

由于备份是从实时实例创建的，因此在备份过程中文件可能会被修改。在这种情况下，可以使用备用策略来备份文件。rsync 工具会创建一个文件副本进行备份，并将它们传递给 tar 进行归档。

{{< alert type=”note” >}}

如果你正在使用这种策略，运行备份 Rake 任务的机器必须有足够的存储空间来存放复制的文件和压缩归档。

{{< /alert >}}

备份 ID

备份 ID 是备份归档的唯一标识符。当你需要恢复极狐GitLab，并且有多个备份归档可用时，这些 ID 是至关重要的。

备份归档保存在 config/gitlab.yml 文件中由 backup_path 设置指定的目录中。默认位置是 /var/opt/gitlab/backups。

备份 ID 由以下部分组成：

  • 备份创建的时间戳
  • 日期 (YYYY_MM_DD)
  • 极狐GitLab 版本
  • 极狐GitLab 版本

以下是一个示例备份 ID：1493107454_2018_04_25_10.6.4-ce

备份文件名

默认情况下，文件名遵循 <backup-id>_gitlab_backup.tar 结构。例如，1493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar。

备份信息文件

备份信息文件 backup_information.yml 保存所有未包含在备份中的备份输入。该文件保存在备份暂存目录中。子任务使用此文件来确定如何恢复和将备份中的数据与外部服务连接，如服务器端仓库备份。

备份信息文件包括以下内容：

  • 备份创建的时间。
  • 生成备份的极狐GitLab 版本。
  • 其他指定选项。例如，跳过的子任务。

备份暂存目录

备份暂存目录是备份和恢复过程中的临时存储位置。此目录：

  • 在创建极狐GitLab 备份归档之前存储备份产物。
  • 在恢复备份或创建增量备份之前提取备份归档。

备份暂存目录是创建完成备份归档的同一目录。当创建未压缩的备份时，备份产物保留在此目录中，并且不会创建归档。

以下是包含未压缩备份的备份暂存目录示例：

backups/
├── 1701728344_2023_12_04_16.7.0-pre_gitlab_backup.tar
├── 1701728447_2023_12_04_16.7.0-pre_gitlab_backup.tar
├── artifacts.tar.gz
├── backup_information.yml
├── builds.tar.gz
├── ci_secure_files.tar.gz
├── db
│   ├── ci_database.sql.gz
│   └── database.sql.gz
├── lfs.tar.gz
├── packages.tar.gz
├── pages.tar.gz
├── repositories
│   ├── manifests/
│   ├── @hashed/
│   └── @snippets/
├── terraform_state.tar.gz
└── uploads.tar.gz