Skip to content

feat: support custom s3 target for backup storage

What does this MR do?

This issue add support to upload backups to a different s3 from the one used by GitLab instance.

This is achieved by adding an option to the backup-utility command to allow a different s3cmd config for the manipulation of the backup archive.

Related issues

Checklist

See Definition of done.

For anything in this list which will not be completed, please provide a reason in the MR discussion

Required

  • Merge Request Title, and Description are up to date, accurate, and descriptive
  • MR targeting the appropriate branch
  • MR has a green pipeline on GitLab.com

Expected (please provide an explanation if not completing)

  • Test plan indicating conditions for success has been posted and passes
  • Documentation created/updated
  • Integration tests added to GitLab QA
  • The impact any change in container size has should be evaluated

Testing

We deployed a custom cluster with a GitLab Helm Chart instance with the following values:

global:
  hosts:
    domain: test-gitlab.s7e.ovh
  ingress:
    annotations:
      cert-manager.io/cluster-issuer: letsencrypt
certmanager-issuer:
  email: philippe@smartfire.pro
gitlab:
  task-runner:
    image:
      repository: registry.gitlab.com/philippevienne/cng/gitlab-task-runner
      tag: latest
    enabled: true
    extraVolumeMounts: |-
      - name: gitlab-backup-s3
        readOnly: true
        mountPath: "/etc/s3-backup"
    extraVolumes: |-
      - name: gitlab-backup-s3
        secret:
          secretName: gitlab-backup-s3
    backups:
      cron:
        enabled: true
        extraArgs: --s3config /etc/s3-backup/.s3cfg --skip registry,artifacts,builds
        resources:
          limits:
            memory: 7G
          requests:
            cpu: 50m
            memory: 2G
        schedule: 10 * * * *

We created a secret named gitlab-backup-s3 with a valid s3cmd config on key .s3cfg.

Edited by Philippe Vienne

Merge request reports

Loading