备份归档过程

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

为了创建归档文件，备份脚本会执行以下操作：

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

备份数据库

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

  1. 使用 pg_dump 创建一个 SQL 转储。
  2. 将 pg_dump 的输出通过 gzip 压缩并创建一个压缩的 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 仓库的一种高效方式。这种方法的优点是：

  • 数据不会通过 Gitaly 进行 RPC 传输。
  • 服务器端备份需要较少的网络传输。
  • 不需要在运行备份 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 进行归档。

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

备份 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