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일 경우, 백업 아티팩트는 이 디렉토리에 남고 아카이브는 생성되지 않습니다.

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-backup이라는 Gitaly 명령을 사용하여 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 클러스터에 구성된 저장소는 독립형 Gitaly과 동일하게 백업됩니다. Gitaly 클러스터가 gitaly-backup에서 RPC 호출을 받으면 자체 데이터베이스를 다시 작성합니다. 이는 Gitaly 클러스터 데이터베이스를 별도로 백업할 필요가 없음을 의미합니다. 백업이 RPC를 통해 작동하기 때문에 각 저장소는 복제 팩터에 관계없이 한 번만 백업됩니다.

서버 측 저장소 백업

서버 측 저장소 백업을 저장소 백업으로 구성할 수 있습니다. 지정된 경우 gitaly-backup은 백업을 생성하기 위해 각 저장소에 대해 단일 RPC 호출을 수행합니다. 이 RPC는 저장소 데이터를 전송하지 않습니다. 대신, RPC는 해당 물리적 저장소를 저장하는 Gitaly 노드를 트리거하여 백업 데이터를 직접 객체 저장소에 업로드합니다. Gitaly를 통해 전송되는 것이 아니기 때문에 서버 측 백업은 훨씬 적은 네트워크 전송이 필요하며 백업을 실행하는 기계에 디스크 저장 공간이 필요하지 않습니다. 객체 저장소에 저장된 백업은 백업 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 작업을 실행하는 기계에는 복사된 파일과 압축된 아카이브를 위한 충분한 저장 공간이 있어야 합니다.

관련 기능