备份极狐GitLab 安装

极狐GitLab 备份通过运行 chart 中 Toolbox pod 内提供的 backup-utility 命令来完成。您还可以通过启用此 chart 的基于 Cron 的备份功能来自动化备份。

在首次运行备份之前，您应确保 Toolbox 已正确配置 以访问对象存储。

请按照以下步骤备份基于 GitLab Helm chart 的安装。

创建备份#

1. 通过执行以下命令，确保 toolbox pod 正在运行

   shell
   kubectl get pods -lrelease=<release_name>,app=toolbox

   将 <release_name> 替换为 Helm release 的名称，通常是 gitlab。

2. 运行备份工具

   shell
   kubectl exec <Toolbox pod name> -it -- backup-utility

3. 访问对象存储服务中的 gitlab-backups 存储桶，并确保已添加一个 tarball。它将按照 <backup_ID>_gitlab_backup.tar 格式命名。了解备份 ID的相关信息。

4. 此 tarball 是恢复所必需的。

基于 Cron 的备份#

您可以在此 chart 中启用基于 Cron 的备份，使其按照 Kubernetes 调度定义的间隔定期执行。

您需要设置以下参数：

• gitlab.toolbox.backups.cron.enabled：设置为 true 以启用基于 Cron 的备份
• gitlab.toolbox.backups.cron.schedule：按照 Kubernetes 调度文档进行设置
• gitlab.toolbox.backups.cron.extraArgs：可选地为 backup-utility 设置额外参数（例如 --skip db 或 --s3tool awscli）

备份工具额外参数#

备份工具可以接受一些额外参数。

跳过组件#

使用 --skip 参数跳过组件。有效的组件名称可以在从备份中排除特定数据中找到。

每个组件必须有自己的 --skip 参数。例如：

shell
kubectl exec <Toolbox pod name> -it -- backup-utility --skip db --skip lfs

仅清理备份#

在不创建新备份的情况下运行备份清理。

shell
kubectl exec <Toolbox pod name> -it -- backup-utility --cleanup

指定要使用的 S3 工具#

backup-utility 命令默认使用 s3cmd 连接到对象存储。 在 s3cmd 不如其他 S3 工具可靠的情况下，您可能希望覆盖此额外参数。

有一个已知问题， 当极狐GitLab 使用 S3 存储桶作为 CI 作业产物存储，并且使用默认的 s3cmd CLI 工具时， 备份作业会因 ERROR: S3 error: 404 (NoSuchKey): The specified key does not exist. 而崩溃。 将 s3cmd 切换为 awscli 可以使备份作业成功运行。 有关更多详细信息，请参阅议题 3338。

要使用的 S3 CLI 工具可以是 s3cmd 或 awscli。

shell
kubectl exec <Toolbox pod name> -it -- backup-utility --s3tool awscli

使用服务账号的 IAM 角色（IRSA）#

如果 Toolbox pod 使用服务账号的 IAM 角色（IRSA）进行身份验证，而不是使用静态 AWS 凭据，则 s3cmd 会因没有可用的 .s3cfg 文件而以 ERROR: /home/git/.s3cfg: None 错误失败。 awscli 没有此要求，因此请使用 --s3tool awscli 切换到它，并完全跳过 gitlab.toolbox.backups.objectStorage.config 密钥：

yaml
1gitlab:
2  toolbox:
3    backups:
4      cron:
5        enabled: true
6        schedule: "@daily"
7        extraArgs: "--s3tool awscli"

要了解有关配置 ServiceAccount 注解的更多信息，请参阅使用 GitLab chart 时的 AWS IAM 角色。

将 MinIO 与 awscli 结合使用#

要在使用 awscli 时将 MinIO 用作对象存储，请设置以下参数：

yaml
1gitlab:
2  toolbox:
3    extraEnvFrom:
4      AWS_ACCESS_KEY_ID:
5        secretKeyRef:
6          name: <MINIO-SECRET-NAME>
7          key: accesskey
8      AWS_SECRET_ACCESS_KEY:
9        secretKeyRef:
10          name: <MINIO-SECRET-NAME>
11          key: secretkey
12    extraEnv:
13      AWS_DEFAULT_REGION: us-east-1 # MinIO default
14    backups:
15      cron:
16        enabled: true
17        schedule: "@daily"
18        extraArgs: "--s3tool awscli --aws-s3-endpoint-url <MINIO-INGRESS-URL>"

S3 CLI 工具 s5cmd 的支持正在调查中。 请参阅议题 523 以跟踪进展。

使用 awscli 的数据完整性保护#

toolbox 中包含的 awscli 工具的新版本默认强制执行数据完整性保护。如果您的对象存储服务不支持此功能，则可以通过以下方式禁用此要求：

yaml
extraEnv:
  AWS_REQUEST_CHECKSUM_CALCULATION: WHEN_REQUIRED

该配置可以是 toolbox pod 的 extraEnv 或全局的 extraEnv。

服务端代码仓库备份#

与其在备份归档中存储大型代码仓库备份，不如将代码仓库备份配置为：由托管每个代码仓库的 Gitaly 节点负责创建备份并将其流式传输到对象存储。这有助于减少创建和恢复备份所需的网络资源。

请参阅创建服务端代码仓库备份。

其他参数#

要查看完整的可用参数列表，请运行以下命令：

shell
kubectl exec <Toolbox pod name> -it -- backup-utility --help

备份密钥#

您还需要保存一份 rails 密钥的副本，因为出于安全考虑，这些内容不包含在备份中。我们建议将包含数据库的完整备份与密钥副本分开存放。

1. 查找 rails 密钥的对象名称

   shell
   kubectl get secrets | grep rails-secret

2. 保存一份 rails 密钥的副本

   shell
   kubectl get secrets <rails-secret-name> -o jsonpath="{.data['secrets\.yml']}" | base64 --decode > gitlab-secrets.yaml

3. 将 gitlab-secrets.yaml 存放在安全的位置。恢复备份时需要用到它。

其他信息#

• GitLab chart 备份/恢复简介
• 恢复极狐GitLab 安装