备份极狐GitLab 安装

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

在第一次运行备份之前，您应该确保 Toolbox 已正确配置，用于访问对象存储

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

创建备份

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

    kubectl get pods -lrelease=RELEASE_NAME,app=toolbox

  2. 运行备份实用程序。 

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

  3. 访问对象存储服务中的 gitlab-backups 存储桶并确保已添加 tarball。 它将以 <timestamp>_<version>_gitlab_backup.tar 格式命名。

  4. 后续恢复需要此 tarball。

基于 Cron 的备份

noteHelm Chart 创建的 Kubernetes CronJob 在 jobTemplate 上设置了 cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 注释。 某些 Kubernetes 环境（例如 GKE Autopilot）不允许设置此注解，并且不会为备份创建 Job Pod。您可以通过将 gitlab.toolbox.backups.cron.safeToEvict 参数设置为 true 来更改此注释，允许创建作业，但存在被驱逐和损坏备份的风险。

可以在此 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）

备份实用程序额外参数

备份实用程序可以采用一些额外的参数： 

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

备份过程使用额外参数

备份过程可以使用一些额外的参数。

跳过组件

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

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

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

仅清除备份

仅清理备份而不创建新备份。 

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

指定使用 S3 工具

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

有一个已知问题：备份作业崩溃且报 ERROR: S3 error: 404 (NoSuchKey): The specified key does not exist. 错误。当 GitLab 使用 S3 存储桶作为 CI 作业工件存储时，可能会出现这种情况，并且默认情况下使用 s3cmd CLI 工具。将 s3cmd 切换到 awscli 允许备份作业成功运行。

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

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

为 MinIO 使用 awscli

当使用 awscli 时将 MinIO 当作对象存储，并设置以下参数： 

gitlab:
  toolbox:
    extraEnvFrom:
      AWS_ACCESS_KEY_ID:
        secretKeyRef:
          name: <MINIO-SECRET-NAME>
          key: accesskey
      AWS_SECRET_ACCESS_KEY:
        secretKeyRef:
          name: <MINIO-SECRET-NAME>
          key: secretkey
    extraEnv:
      AWS_DEFAULT_REGION: us-east-1 # MinIO default
    backups:
      cron:
        enabled: true
        schedule: "@daily"
        extraArgs: "--s3tool awscli --aws-s3-endpoint-url <MINIO-INGRESS-URL>"
note对 S3 CLI 工具 s5cmd 的支持正在调查中。

Server-side repository backups

  • 自极狐GitLab 17.0 引入。

可以配置存储库备份，而不是将大型存储库备份存储在备份归档中，这样托管每个存储库的 Gitaly 节点就负责创建备份并将其流式传输到对象存储。这有助于减少创建和恢复备份所需的网络资源。

查阅创建服务端侧镜像仓库备份。

其他参数

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

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

备份 secrets

您还应该保存一份 rails secrets 的副本。（作为安全预防措施，这些不包括在备份中。我们建议将包含数据库的完整备份与 secret 副本分开。）

  1. 查找 rails secrets 的对象名称 

    kubectl get secrets | grep rails-secret

  2. 保存一份 rails secret 的副本 

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

  3. 将 gitlab-secrets.yaml 存储在一个安全的位置，您可能需要它来完全恢复您的备份。

额外信息