• 데이터베이스 백업
• Git 저장소 백업
  • 서버 측 백업
• 파일 백업
• 백업 ID
• 백업 파일 이름
• 백업 정보 파일
• 백업 스테이징 디렉토리

백업 아카이브 프로세스

백업 명령을 실행하면, 백업 스크립트가 GitLab 데이터를 저장하기 위한 백업 아카이브 파일을 생성합니다.

아카이브 파일을 생성하기 위해, 백업 스크립트는:

1. 증분 백업을 수행할 때 이전 백업 아카이브 파일을 추출합니다.

2. 백업 아카이브 파일을 업데이트하거나 생성합니다.

3. 모든 백업 하위 작업을 실행합니다:

   • 데이터베이스 백업.
   • Git 저장소 백업.
   • 파일 백업.

4. 백업 스테이징 영역을 tar 파일로 아카이브합니다.

5. 새 백업 아카이브를 객체 저장소에 업로드합니다, 구성된 경우.

6. 아카이브된 백업 스테이징 디렉토리 파일을 정리합니다.

데이터베이스 백업

데이터베이스를 백업하기 위해, db 하위 작업은:

1. pg_dump를 사용하여 SQL 덤프를 생성합니다.

2. pg_dump의 출력을 gzip으로 파이핑하여 압축된 SQL 파일을 생성합니다.

3. 해당 파일을 백업 스테이징 디렉토리에 저장합니다.

Git 저장소 백업

Git 저장소를 백업하기 위해, repositories 하위 작업은:

1. gitaly-backup에 어떤 저장소를 백업할지 알립니다.

2. gitaly-backup을 실행하여:

   • Gitaly에서 일련의 원격 프로시저 호출(RPC)을 호출합니다.
   • 각 저장소에 대한 백업 데이터를 수집합니다.

3. 수집된 데이터를 백업 스테이징 디렉토리의 디렉토리 구조로 스트리밍합니다.

다음 다이어그램은 프로세스를 설명합니다:

Gitaly 클러스터 구성된 스토리지는 독립 실행형 Gitaly 인스턴스와 같은 방식으로 백업됩니다.

• Gitaly 클러스터가 gitaly-backup에서 RPC 호출을 받으면, 자신의 데이터베이스를 재구성합니다.

  • Gitaly 클러스터 데이터베이스를 별도로 백업할 필요는 없습니다.

• 각 저장소는 복제 계수에 관계없이 한 번만 백업되며, 백업은 RPC를 통해 운영됩니다.

서버 측 백업

서버 측 저장소 백업은 Git 저장소를 백업하는 효율적인 방법입니다.

이 방법의 장점은:

• 데이터가 Gitaly에서 RPC를 통해 전송되지 않습니다.
• 서버 측 백업은 네트워크 전송이 적습니다.
• 백업 Rake 작업을 실행하는 기계에서 디스크 저장소가 필요하지 않습니다.

서버 측에서 Gitaly를 백업하기 위해, repositories 하위 작업은:

1. 각 저장소에 대해 단일 RPC 호출을 하기 위해 gitaly-backup을 실행합니다.

2. 물리적 저장소를 저장하는 Gitaly 노드를 트리거하여 객체 저장소에 백업 데이터를 업로드합니다.

3. 생성된 백업 아카이브에 객체 저장소에 저장된 백업 링크를 백업 ID를 사용하여 연결합니다.

다음 다이어그램은 프로세스를 설명합니다:

파일 백업

다음 하위 작업은 파일을 백업합니다:

• uploads: 첨부 파일
• builds: CI/CD 작업 출력 로그
• artifacts: CI/CD 작업 아티팩트
• pages: 페이지 내용
• lfs: LFS 객체
• terraform_state: Terraform 상태
• registry: 컨테이너 레지스트리 이미지
• packages: 패키지
• ci_secure_files: 프로젝트 수준의 보안 파일
• external_diffs: 병합 요청의 차이(외부에 저장될 때)

각 하위 작업은 작업 특정 디렉토리에서 파일 집합을 식별하고:

1. tar 유틸리티를 사용하여 식별된 파일의 아카이브를 생성합니다.

2. 디스크에 저장하지 않고 gzip를 통해 아카이브를 압축합니다.

3. tar 파일을 백업 스테이징 디렉토리로 저장합니다.

백업은 실시간 인스턴스에서 생성되기 때문에 파일이 백업 과정 중에 수정될 수 있습니다.

이 경우, 파일을 백업하기 위해 대체 전략을 사용할 수 있습니다. rsync 유틸리티는 백업할 파일의 복사본을 생성하고 이를 아카이빙을 위해 tar로 전달합니다.

참고: 이 전략을 사용하는 경우, 백업 Rake 작업을 실행하는 머신에는 복사된 파일 및 압축된 아카이브 모두에 대해 충분한 저장 공간이 있어야 합니다.

백업 ID

백업 ID는 백업 아카이브의 고유 식별자입니다. 이러한 ID는 GitLab을 복원해야 할 때 중요하며, 여러 백업 아카이브가 있는 경우에 필요합니다.

백업 아카이브는 config/gitlab.yml 파일의 backup_path 설정에 의해 지정된 디렉토리에 저장됩니다.

기본 위치는 /var/opt/gitlab/backups입니다.

백업 ID는 다음으로 구성됩니다:

• 백업 생성 시간
• 날짜 (YYYY_MM_DD)
• GitLab 버전
• GitLab 에디션

다음은 백업 ID의 예입니다: 1493107454_2018_04_25_10.6.4-ce

백업 파일 이름

기본적으로 파일 이름은 <backup-id>_gitlab_backup.tar 구조를 따릅니다. 예를 들어, 1493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar입니다.

백업 정보 파일

백업 정보 파일인 backup_information.yml은 백업에 포함되지 않은 모든 백업 입력을 저장합니다. 이 파일은 백업 스테이징 디렉토리에 저장됩니다.

하위 작업은 이 파일을 사용하여 백업을 복원하고 외부 서비스와의 데이터 링크를 설정하는 방법을 결정합니다. 예를 들어 서버 측 리포지토리 백업.

백업 정보 파일에는 다음이 포함됩니다:

• 백업이 생성된 시간.
• 백업을 생성한 GitLab 버전.
• 기타 지정된 옵션. 예를 들어, 건너뛴 하위 작업.

백업 스테이징 디렉토리

백업 스테이징 디렉토리는 백업 및 복원 프로세스 중에 사용되는 임시 저장 위치입니다. 이 디렉토리는:

• GitLab 백업 아카이브를 생성하기 전에 백업 아티팩트를 저장합니다.
• 백업을 복원하거나 증분 백업을 생성하기 전에 백업 아카이브를 추출합니다.

백업 스테이징 디렉토리는 완료된 백업 아카이브가 생성되는 동일한 디렉토리입니다.

언타르드 백업을 생성할 때, 백업 아티팩트는 이 디렉토리에 남아 있으며 아카이브는 생성되지 않습니다.

다음은 언타르드 백업을 포함하는 백업 스테이징 디렉토리의 예입니다:

backups/
├── 1701728344_2023_12_04_16.7.0-pre_gitlab_backup.tar
├── 1701728447_2023_12_04_16.7.0-pre_gitlab_backup.tar
├── artifacts.tar.gz
├── backup_information.yml
├── 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
├── repositories
│   ├── manifests/
│   ├── @hashed/
│   └── @snippets/
├── terraform_state.tar.gz
└── uploads.tar.gz