GitLab 설치 백업

Tier: Free, Premium, Ultimate Offering: Self-Managed

GitLab 백업은 차트에서 제공되는 Toolbox pod에서 backup-utility 명령을 실행하여 수행됩니다. 또한 이 차트의 기반 백업 자동화 기능을 활성화시킴으로써 백업을 자동화할 수도 있습니다.

첫 번째로 백업을 실행하기 전에 Toolbox가 객체 리포지터리에 액세스하기 위해 올바르게 구성되었는지 확인해야 합니다.

GitLab Helm 차트 기반 설치의 백업을 위해 다음 단계를 따르세요.

백업 생성

  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>_gitlab_backup.tar 형식으로 지정됩니다. 백업 타임스탬프가 무엇인지 읽어보세요.
  4. 이 tarball은 복원에 필요합니다.

크론 기반 백업

note
Helm 차트에서 생성된 Kubernetes CronJob은 작업 템플릿에 cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 주석을 설정합니다. GKE Autopilot과 같은 일부 Kubernetes 환경은 이 주석을 설정할 수 없으며 백업을 위한 작업 Pod를 생성하지 않습니다. 이 주석은 gitlab.toolbox.backups.cron.safeToEvict 매개변수를 true로 설정하여 변경할 수 있으며, 이를 통해 작업을 만들 수 있지만 추방될 가능성과 백업의 손상이 있을 수 있습니다.

크론 기반 백업은 정기적인 간격으로 이 차트에서 활성화될 수 있으며, 이는 Kubernetes 스케줄에서 정의된 대로 발생합니다.

다음 매개변수를 설정해야 합니다:

  • gitlab.toolbox.backups.cron.enabled: 크론 기반 백업을 활성화하려면 true로 설정합니다.
  • gitlab.toolbox.backups.cron.schedule: Kubernetes 스케줄 문서에 따라 설정합니다.
  • gitlab.toolbox.backups.cron.extraArgs: 선택적으로 백업-유틸리티에 대한 추가 인수를 설정합니다(예: --skip db 또는 --s3tool awscli).

백업 유틸리티 추가 인수

백업 유틸리티에는 몇 가지 추가 인수가 있습니다.

컴포넌트 건너뛰기

--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보다 신뢰성이 낮은 경우 이 추가 인수를 재정의할 수 있습니다.

알려진 이슈가 있습니다(https://gitlab.com/gitlab-org/charts/gitlab/-/issues/3338).

백업 작업이 ‘ERROR: S3 error: 404 (NoSuchKey): The specified key does not exist.’와 함께 충돌하는 경우가 있습니다. 이 문제는 GitLab이 CI 작업 artifact 리포지터리로 S3 버킷을 사용하고 기본 ‘s3cmd’ CLI 도구를 사용할 때 발생합니다. ‘s3cmd’에서 ‘awscli’로 전환하면 백업 작업이 성공적으로 실행됩니다. 더 자세한 내용은 issue 3338을 참조하세요.

사용할 S3 CLI 도구는 ‘s3cmd’ 또는 ‘awscli’ 일 수 있습니다. 

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

awscli로 MinIO 사용하기

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’의 지원은 조사 중입니다. 진행 상황을 추적하려면 issue 523을 확인하세요.

기타 매개변수

사용 가능한 매개변수 디렉터리을 확인하려면 다음 명령을 실행하세요. 

kubectl exec <Toolbox pod 이름> -it -- backup-utility --help

시크릿 백업

보안상의 이유로 백업에 포함되지 않는 Rails 시크릿의 사본을 저장해야 합니다. 데이터베이스를 포함한 완전한 백업을 유지하는 것이 좋습니다.

  1. Rails 시크릿의 객체 이름 찾기 

    kubectl get secrets | grep rails-secret

  2. Rails 시크릿의 사본 저장 

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

  3. gitlab-secrets.yaml을 안전한 위치에 저장합니다. 백업을 복원하기 위해 필요합니다.

추가 정보