GitLab 백업 및 복원

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

소프트웨어 또는 조직은 GitLab 인스턴스의 데이터에 의존하고 있습니다. 이 데이터가 손상된 데이터, 데이터의 실수로 인한 삭제, 랜섬웨어 공격, 예상치 못한 클라우드 공급자 다운타임과 같은 악영향으로부터 보호되도록 보장해야 합니다.

모든 이러한 리스크를 백업을 포함한 재해 복구 계획으로 완화할 수 있습니다.

GitLab 백업

GitLab을 백업하는 자세한 내용은 GitLab 백업을 참조하십시오.

GitLab 복원

GitLab을 복원하는 자세한 내용은 GitLab 복원을 참조하십시오.

새 서버로 이전

백업 및 복원을 사용하여 새 서버로 마이그레이션하는 자세한 정보는 새 서버로 이전을 참조하십시오.

추가 참고 사항

이 설명서는 GitLab Community 및 Enterprise Edition을 위한 것입니다. 우리는 GitLab.com을 백업하고 데이터가 안전하도록 보장합니다. 그러나 이러한 방법을 사용하여 GitLab.com에서 데이터를 내보내거나 백업하는 데 사용할 수는 없습니다.

이슈는 데이터베이스에 저장되며 Git 자체에는 저장할 수 없습니다.

GitLab 백업 아카이브 생성 프로세스

GitLab 백업을 다룰 때, GitLab이 백업 아카이브를 어떻게 생성하는지 알아둘 필요가 있습니다. 백업 아카이브를 생성하기 위해 GitLab은 다음을 수행합니다:

  1. 증분 백업을 생성하는 경우, 이전 백업 아카이브를 추출하고 그 backup_information.yml 파일을 읽습니다.
  2. backup_information.yml 파일을 업데이트하거나 생성합니다.
  3. 모든 백업 하위 작업을 실행합니다:
    • db: GitLab PostgreSQL 데이터베이스(비 Gitaly Cluster)를 백업합니다.
    • repositories: Git 리포지터리를 백업합니다.
    • uploads: 첨부 파일을 백업합니다.
    • builds: CI 작업 출력 로그를 백업합니다.
    • artifacts: CI 작업 아티팩트를 백업합니다.
    • pages: 페이지 콘텐츠를 백업합니다.
    • lfs: LFS 객체를 백업합니다.
    • terraform_state: Terraform 상태를 백업합니다.
    • registry: 컨테이너 레지스트리 이미지를 백업합니다.
    • packages: 패키지를 백업합니다.
    • ci_secure_files: 프로젝트 수준의 보안 파일을 백업합니다.
  4. 백업 스테이징 영역을 tar 파일로 아카이브합니다.
  5. 선택 사항. 새로운 백업 아카이브를 객체 리포지터리에 업로드합니다.
  6. 이제 아카이빙된 백업 스테이징 디렉터리 파일을 정리합니다.

백업 ID

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

백업 아카이브는 config/gitlab.yml 파일에서 지정된 backup_path에 저장됩니다.

  • 기본적으로 백업 아카이브는 /var/opt/gitlab/backups에 저장됩니다.
  • 기본적으로 백업 아카이브 파일 이름은 <백업-id>_gitlab_backup.tar이며 <백업-id>는 백업 아카이브가 생성된 시간, GitLab 버전 및 GitLab 에디션을 식별합니다.

예를 들어, 아카이브 파일이 1493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar인 경우, 백업 ID는 1493107454_2018_04_25_10.6.4-ce입니다.

백업 스테이징 디렉터리

백업 스테이징 디렉터리는 다음과 같은 일시적인 작업 공간으로 사용됩니다:

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

이 디렉터리는 완료된 GitLab 백업 아카이브가 생성되는 동일한 디렉터리입니다. 백업을 해제한 경우, 백업 아티팩트는 이 디렉터리에 남고 아카이브는 생성되지 않습니다.

untarred 백업이 있는 백업 스테이징 디렉터리의 예시: 

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

backup_information.yml 파일

backup_information.yml 파일은 백업 자체에 포함되지 않는 모든 백업 입력을 저장합니다. 이 파일에는 다음과 같은 정보가 포함됩니다:

  • 백업이 생성된 시간
  • 백업을 생성한 GitLab 버전
  • 생략된 하위 작업과 같은 지정된 옵션

일부 하위 작업에서 이 정보는 다음을 결정하는 데 사용됩니다:

  • 복원하는 방법
  • 백업 데이터를 외부 서비스(예: 서버 측 리포지터리 백업)와 연결하는 방법

이 파일은 백업 스테이징 디렉터리에 저장됩니다.

데이터베이스 백업

데이터베이스 백업은 GitLab 백업 하위 작업인 db에 의해 생성 및 복원됩니다. 데이터베이스 하위 작업은 pg_dump를 사용하여 SQL 덤프를 생성합니다. pg_dump의 출력은 압축된 SQL 파일을 생성하기 위해 gzip로 파이프됩니다. 이 파일은 백업 스테이징 디렉터리에 저장됩니다.

리포지터리 백업

리포지터리 백업은 GitLab 백업 하위 작업인 repositories에 의해 생성 및 복원됩니다. 리포지터리 하위 작업은 Gitaly 명령인 gitaly-backup을 사용하여 Git 리포지터리 백업을 생성합니다:

  • GitLab은 gitaly-backup에 백업해야 할 리포지터리를 알리기 위해 데이터베이스를 사용합니다.
  • gitaly-backup은 그런 다음 각 리포지터리의 백업 데이터를 수집하기 위해 Gitaly에서 일련의 RPC를 호출합니다. 이 데이터는 GitLab 백업 스테이징 디렉터리의 디렉터리 구조로 스트리밍됩니다.
sequenceDiagram box 백업 호스트 participant 리포지터리 하위 작업 participant gitaly-backup end 리포지터리 하위 작업->>+gitaly-backup: 리포지터리 디렉터리 loop 각 리포지터리 gitaly-backup->>+Gitaly: ListRefs 요청 Gitaly->>-gitaly-backup: Git 레퍼런스 디렉터리 gitaly-backup->>+Gitaly: CreateBundleFromRefList 요청 Gitaly->>-gitaly-backup: Git 번들 파일 gitaly-backup->>+Gitaly: GetCustomHooks 요청 Gitaly->>-gitaly-backup: 커스텀 후크 아카이브 end gitaly-backup->>-리포지터리 하위 작업: 성공/실패

Gitaly Cluster로 구성된 스토리지는 독립형 Gitaly와 동일하게 백업됩니다. Gitaly Cluster가 gitaly-backup의 RPC 호출을 받으면 자체 데이터베이스를 다시 빌드합니다. 이는 Gitaly Cluster 데이터베이스를 별도로 백업할 필요가 없음을 의미합니다. 백업은 RPC를 통해 작동하기 때문에 복제 요소에 관계없이 각 리포지터리는 한 번만 백업됩니다.

서버 측 리포지터리 백업

서버 측 리포지터리 백업을 구성할 수 있습니다. 지정된 경우 gitaly-backup은 백업을 생성하기 위해 각 리포지터리마다 단일 RPC 호출을 수행합니다. 이 RPC는 리포지터리 데이터를 전송하지 않습니다. 대신, RPC는 해당 물리적 리포지터리를 저장하는 Gitaly 노드를 트리거하여 백업 데이터를 개체 리포지터리에 직접 업로드합니다. Gitaly를 통해 데이터가 더 이상 전송되지 않기 때문에 서버 측 백업은 네트워크 전송이 훨씬 적게 필요하며 백업 Rake 작업을 실행하는 머신에 디스크 저장 공간이 필요하지 않습니다. 개체 리포지터리에 저장된 백업은 백업 ID에 의해 생성된 백업 아카이브에 연결됩니다.

sequenceDiagram box 백업 호스트 participant 리포지터리 하위 작업 participant gitaly-backup end 리포지터리 하위 작업->>+gitaly-backup: 리포지터리 디렉터리 loop 각 리포지터리 gitaly-backup->>+Gitaly: BackupRepository 요청 Gitaly->>+개체 리포지터리: Git 참조 파일 개체 리포지터리->>-Gitaly: 성공/실패 Gitaly->>+개체 리포지터리: Git 번들 파일 개체 리포지터리->>-Gitaly: 성공/실패 Gitaly->>+개체 리포지터리: 사용자 정의 후크 아카이브 개체 리포지터리->>-Gitaly: 성공/실패 Gitaly->>+개체 리포지터리: 백업 매니페스트 파일 개체 리포지터리->>-Gitaly: 성공/실패 Gitaly->>-gitaly-backup: 성공/실패 end gitaly-backup->>-리포지터리 하위 작업: 성공/실패

파일 백업

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

  • uploads
  • builds
  • artifacts
  • pages
  • lfs
  • terraform_state
  • registry
  • packages
  • ci_secure_files

이 파일 하위 작업은 해당 작업에 특정한 디렉터리 내의 파일을 결정합니다. 그런 다음 해당 파일 세트는 아카이브를 만들기 위해 tar에 전달됩니다. 이 아카이브는 (디스크에 저장되지 않음) 백업 스테이징 디렉터리에 압축된 tar 파일을 저장하기 위해 gzip을 통해 파이프됩니다.

백업은 라이브 인스턴스에서 생성되기 때문에, tar가 아카이브를 만드는 동안에 아카이브할 파일이 가끔 수정될 수 있습니다. 이 경우 대체 “복사” 전략을 사용할 수 있습니다. 이 전략을 사용하는 경우, rsync를 사용하여 백업할 파일의 사본을 먼저 만듭니다. 그런 다음 이러한 사본들이 보통대로 tar에 전달됩니다. 이 경우 백업 Rake 작업을 실행하는 머신은 복사된 파일과 압축된 아카이브를 위한 충분한 저장 공간이 있어야 합니다.

관련 기능