gitlab-backup-cli를 사용한 GitLab 백업 및 복원

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

이 도구는 개발 중이며 궁극적으로 GitLab을 백업하고 복원하는 데 사용되는 Rake 작업을 대체하기 위한 것입니다. 이 도구의 개발은 epic에서 확인할 수 있습니다: Next Gen Scalable Backup and Restore.

이 도구에 대한 피드백은 피드백 이슈에 환영합니다.

백업하기

현재의 GitLab 설치를 백업하려면: 

sudo gitlab-backup-cli backup all

객체 저장소 백업

현재 구글 클라우드만 지원됩니다. 더 많은 공급업체를 추가하기 위한 계획은 epic 11577을 참조하세요.

GCP

gitlab-backup-cli는 Google Transfer Service를 사용하여 GitLab 데이터를 별도의 백업 버킷으로 복사하는 작업을 생성하고 실행합니다.

필수 조건:

  • 인증에 관해 Google 문서를 따르세요.
  • 본 문서에서는 백업을 관리하기 위해 전용 구글 클라우드 서비스 계정을 설정하고 사용한다고 가정합니다.
  • 다른 인증 정보가 제공되지 않은 경우, 그리고 Google Cloud 내에서 실행 중이라면, 해당 도구는 실행 중인 인프라의 액세스를 사용하려고 시도합니다. 별도의 인증 정보를 사용하고, 생성된 백업에 대한 액세스를 제한하는 것이 좋습니다.

백업 생성:

  1. 롤 생성하기:
    1. 다음의 정의를 가진 role.yaml 파일을 생성하세요: 
    ---
description: GitLab 객체 저장소를 위한 롤
includedPermissions:
   - storagetransfer.jobs.create
   - storagetransfer.jobs.get
   - storagetransfer.jobs.run
   - storagetransfer.jobs.update
   - storagetransfer.operations.get
   - storagetransfer.projects.getServiceAccount
stage: GA
title: GitLab 백업 롤

    1. 롤 적용하기: 

      gcloud iam roles create --project=<YOUR_PROJECT_ID> <ROLE_NAME> --file=role.yaml

  2. 백업용 서비스 계정 생성하고 롤에 추가하기: 

    gcloud iam service-accounts create "gitlab-backup-cli" --display-name="GitLab Backup Service Account"
# 서비스 계정 이메일을 다음의 출력에서 가져오세요
gcloud iam service-accounts list
# 계정을 이전에 생성한 롤에 추가하세요
gcloud projects add-iam-policy-binding <YOUR_PROJECT_ID> --member="serviceAccount:<SERVICE_ACCOUNT_EMAIL>" --role="roles/<ROLE_NAME>"
  3. Google 문서를 따라 서비스 계정으로의 인증을 완료하세요. 일반적으로, 자격 증명은 파일에 저장하거나 사전에 정의된 환경 변수에 저장될 수 있습니다.
  4. Google Cloud Storage에 백업을 하기 위한 대상 버킷을 생성하세요. 여기서의 옵션은 귀하의 요구에 매우 의존적입니다.

  5. 백업 실행: 

    sudo gitlab-backup-cli backup all --backup-bucket=<BUCKET_NAME>

    컨테이너 레지스트리 버킷을 백업하려면 --registry-bucket=<REGISTRY_BUCKET_NAME> 옵션을 추가하세요.

  6. 백업은 각 버킷의 객체 저장소 유형마다 backups/<BACKUP_ID>/<BUCKET> 아래에 백업을 생성합니다.

백업 디렉토리 구조

예시 백업 디렉토리 구조: 

backups
└── 1714053314_2024_04_25_17.0.0-pre
    ├── artifacts.tar.gz
    ├── backup_information.json
    ├── builds.tar.gz
    ├── ci_secure_files.tar.gz
    ├── db
    │   ├── ci_database.sql.gz
    │   └── database.sql.gz
    ├── lfs.tar.gz
    ├── packages.tar.gz
    ├── pages.tar.gz
    ├── registry.tar.gz
    ├── repositories
    │   ├── default
    │   │   ├── @hashed
    │   │   └── @snippets
    │   └── manifests
    │       └── default
    ├── terraform_state.tar.gz
    └── uploads.tar.gz

db 디렉터리는 pg_dump를 사용하여 GitLab PostgreSQL 데이터베이스를 백업하여 SQL 덤프를 생성합니다. pg_dump의 출력은 압축된 SQL 파일을 생성하기 위해 gzip을 통해 파이프됩니다.

repositories 디렉터리는 GitLab 데이터베이스에 있는 Git 리포지토리를 백업하기 위해 사용됩니다.

백업 ID

백업 ID는 개별 백업을 식별합니다. 여러 백업을 사용하여 GitLab을 복원해야 하는 경우 백업 아카이브의 백업 ID가 필요합니다.

백업은 config/gitlab.yml 파일에 지정된 backup_path 디렉터리에 저장됩니다.

  • 기본적으로 백업은 /var/opt/gitlab/backups에 저장됩니다.
  • 기본적으로 백업 디렉터리는 백업이 생성된 시간과 GitLab 버전을 나타내는 <backup-id>를 이름으로 합니다.

예를 들어, 백업 디렉토리 이름이 1714053314_2024_04_25_17.0.0-pre인 경우, 생성 시간은 1714053314_2024_04_25로 나타나고 GitLab 버전은 17.0.0-pre입니다.

백업 메타데이터 파일 (backup_information.json)

  • 메타데이터 버전 2가 GitLab 16.11에서 소개되었습니다.

backup_information.json은 백업 디렉토리에서 찾을 수 있으며, 백업에 대한 메타데이터를 저장합니다. 예를 들어: 

{
  "metadata_version": 2,
  "backup_id": "1714053314_2024_04_25_17.0.0-pre",
  "created_at": "2024-04-25T13:55:14Z",
  "gitlab_version": "17.0.0-pre"
}

알려진 문제

gitlab-backup-cli를 사용하는 경우 다음과 같은 문제가 발생할 수 있습니다.

아키텍처 호환성

1K 아키텍처 이외의 아키텍처에서 gitlab-backup-cli 도구를 사용하는 경우 문제가 발생할 수 있습니다. 이 도구는 1K 아키텍처에서만 지원되며 관련 환경에서만 권장됩니다.

백업 전략

백업 중 기존 파일의 변경이 GitLab 인스턴스에 문제를 일으킬 수 있습니다. 이 문제는 도구의 초기 버전이 복사 전략을 사용하지 않기 때문에 발생합니다.

이 문제의 해결책으로는 다음 중 하나를 선택하실 수 있습니다:

  • GitLab 인스턴스를 유지보수 모드로 전환합니다.
  • 백업 중 서버로의 트래픽을 제한하여 인스턴스 리소스를 보존합니다.

복사 전략 대안에 대해 조사 중이며, 이슈 428520를 참조하십시오.

백업되는 데이터

  1. Git 저장소 데이터
  2. 데이터베이스
  3. 블롭

백업되지 않는 데이터

  1. 비밀 및 구성

  2. 일시적 및 캐시 데이터

    • Redis: 캐시
    • Redis: Sidekiq 데이터
    • 로그
    • Elasticsearch
    • 관측성 데이터 / 프로메테우스 메트릭