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은 jobTemplate의 cluster-autoscaler.kubernetes.io/safe-to-evict: "false" 주석을 설정합니다. GKE Autopilot과 같은 일부 Kubernetes 환경은 이 주석을 허용하지 않으며 백업을 위한 Job Pods를 생성하지 않을 것입니다. gitlab.toolbox.backups.cron.safeToEvict 매개변수를 true로 설정하여 이 주석을 변경할 수 있으며, 이렇게 하면 Job이 생성되지만 위험하게도 퇴거될 수 있고 백업이 손상될 수 있습니다.

크론 기반 백업을 이 차트에서 정의된 Kubernetes 스케줄에 따라 정기적으로 수행하도록 설정할 수 있습니다.

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

  • gitlab.toolbox.backups.cron.enabled: 크론 기반 백업을 활성화하려면 true로 설정합니다.
  • gitlab.toolbox.backups.cron.schedule: Kubernetes 스케줄 문서에 따라 설정합니다.
  • gitlab.toolbox.backups.cron.extraArgs: backup-utility에 대한 추가 인수를 선택적으로 설정합니다(예: --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가 다른 S3 도구보다 신뢰성이 떨어지는 경우 이 추가 인수를 재정의할 수 있습니다.

GitLab이 S3 버킷을 CI 작업 아티팩트 리포지터리로 사용하고 기본 s3cmd CLI 도구를 사용하는 경우 issue 3338에서 설명한 대로 백업 작업이 ERROR: S3 error: 404 (NoSuchKey): The specified key does not exist. 오류로 중단될 수 있는 알려진 문제가 있습니다. 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의 기본값
    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 name> -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을 안전한 위치에 저장하세요. 이것은 백업을 복원하는 데 필요합니다.

추가 정보