markdown # 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 클러스터)의 백업을 수행합니다.
    • 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가 필요합니다.

백업 아카이브는 backup_path에 설정된 디렉터리에 저장되며, 이는 config/gitlab.yml 파일에서 지정됩니다.

  • 기본적으로 백업 아카이브는 /var/opt/gitlab/backups에 저장됩니다.
  • 기본적으로 백업 아카이브 파일 이름은 <backup-id>_gitlab_backup.tar이며, 여기서 <backup-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 백업 아카이브가 생성되기 전에 디스크에 백업 아티팩트를 저장합니다.
  • 백업을 풀어낸 후 복원하거나 증분 백업을 만드는데 사용합니다.

이 디렉터리는 완료된 GitLab 백업 아카이브가 생성되는 동일한 디렉터리입니다. tar 압축 해제된 백업을 만들 때, 백업 아티팩트는 이 디렉터리에 남게 되며 아카이브는 만들어지지 않습니다.

tar 압축을 푼 백업 스테이징 디렉터리의 예시: 

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 클러스터에 구성된 리포지터리는 독립적인 Gitaly와 동일한 방식으로 백업됩니다. Gitaly 클러스터가 gitaly-backup에서 RPC 호출을 받으면, 자체 데이터베이스를 다시 빌드하는 책임이 있습니다. 즉, Gitaly 클러스터 데이터베이스를 별도로 백업할 필요가 없습니다. 백업은 RPC를 통해 작동하기 때문에 복제 요인에 관계없이 각 리포지터리는 한 번만 백업됩니다.

서버 측 리포지터리 백업

서버 측 리포지터리 백업을 리포지터리 백업으로 구성할 수 있습니다. 지정된 경우, gitaly-backup은 각 리포지터리에 대해 백업을 만들기 위해 단일 RPC 호출을 수행합니다. 이 RPC는 리포지터리 데이터를 전송하지 않습니다. 대신, RPC는 해당 물리적 리포지터리를 저장하는 Gitaly 노드를 트리거하여 백업 데이터를 객제 스토리지에 직접 업로드합니다. RPC를 통해 데이터를 더 이상 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->>-리포지터리 하위 작업: 성공/실패

```

All the sentences and the table under DETAILS section are not translated.

파일 백업

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

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

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

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

관련 기능