GitLab 설치 백업

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

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

첫 번째로 백업을 실행하기 전에, Toolbox가 올바르게 구성되었는지 확인해야 하며, 오브젝트 저장소에 접근할 수 있어야 합니다.

GitLab Helm 차트 기반 설치를 백업하는 방법은 다음과 같습니다.

백업 생성

  1. 다음 명령을 실행하여 toolbox 포드가 실행 중인지 확인합니다.

    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 기반 백업

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

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이 CI 작업 아티팩트 저장을 위해 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>"

참고:

S3 CLI 도구 s5cmd 지원은 조사 중입니다.

진행 상황을 추적하려면 문제 523를 참조하세요.

서버 측 리포지토리 백업

대규모 리포지토리 백업을 백업 아카이브에 저장하는 대신, 리포지토리 백업은 각 리포지토리를 호스팅하는 Gitaly 노드가 백업을 생성하고 이를 객체 저장소로 스트리밍하도록 구성할 수 있습니다. 이렇게 하면 백업을 생성하고 복원하는 데 필요한 네트워크 자원을 줄일 수 있습니다.

서버 측 리포지토리 백업 생성하기를 참조하세요.

기타 인수

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

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을 안전한 위치에 저장하세요. 백업을 복원하는 데 필요합니다.

추가 정보