• 백업 생성
• Cron 기반 백업
• 백업 유틸리티 추가 인수
  • 구성 요소 건너뛰기
  • 백업 정리만 실행
  • 사용할 S3 도구 지정
    • awscli로 MinIO 사용하기
  • 서버 측 저장소 백업
  • 기타 인수
• 시크릿 백업
• 추가 정보

GitLab 설치 백업

GitLab 백업은 차트에서 제공된 Toolbox pod에서 backup-utility 명령을 실행하여 수행됩니다. 또한, 백업은 이 차트의 기반된 Cron 기반 백업 기능을 활성화하여 자동화될 수도 있습니다.

처음으로 백업을 실행하기 전에 [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은 복원에 필요합니다.

Cron 기반 백업

이 차트에서 Cron 기반 백업을 활성화하여 Kubernetes 스케줄에 따라 정기적으로 발생하도록 설정할 수 있습니다.

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

• gitlab.toolbox.backups.cron.enabled: Cron 기반 백업을 활성화하려면 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-org/charts/gitlab/-/issues/3338에서 알려진 문제는 GitLab이 CI 작업 artefact 저장소로 S3 버킷을 사용하고 기본 s3cmd CLI 도구를 사용할 때 백업 작업이 ERROR: S3 error: 404 (NoSuchKey): The specified key does not exist.와 함께 충돌하는 문제를 보고하고 있습니다. s3cmd에서 awscli로 전환하면 백업 작업이 성공적으로 실행됩니다. 추가 세부 정보는 이슈 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>"

서버 측 저장소 백업

• GitLab 17.0에서 도입되었습니다.

백업 아카이브에 대형 저장소 백업을 저장하는 대신 각 저장소를 호스트하는 Gitaly 노드가 백업을 생성하고 객체 저장소로 스트리밍하는 방식으로 저장소 백업을 구성할 수 있습니다. 이를 통해 백업을 작성하고 복원하는 데 필요한 네트워크 리소스를 줄일 수 있습니다.

서버 측 저장소 백업 생성을 참조하세요.

기타 인수

사용 가능한 인수의 전체 목록을 보려면 다음 명령을 실행하세요:

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

시크릿 백업

또한 보안상의 이유로 시크릿은 백업에 포함되지 않으므로 별도로 레일즈 시크릿의 사본을 저장해야 합니다. 데이터베이스를 포함한 전체 백업은 따로 유지하는 것이 좋습니다.

1. 레일즈 시크릿의 객체 이름 찾기

   kubectl get secrets | grep rails-secret
   

2. 레일즈 시크릿의 사본 저장

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

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

추가 정보

• GitLab 차트 백업/복원 소개
• GitLab 설치 복원