GitLab은 설치 유형과 호스팅 아키텍처별로 애플리케이션 백업을 만드는 방법을 안내합니다. 특정 시점의 애플리케이션 백업을 만드는 간단한 도구와 함께, 복잡한 클라우드 기반 설치의 백업을 다루는 별도 문서를 제공합니다.

백업과 복원은 주로 Linux 패키지와 Docker 설치 방식에 함께 제공되는 gitlab-backup 도구를 사용합니다.

Kubernetes 설치에만 제공되는 도구로 구현 방식이 다른 backup-utility도 있습니다.

gitlab-backup 도구#

백업 생성과 복원에 관한 현재 GitLab 문서는 Omnibus로 만든 시스템 패키지에 포함된 전용 명령인 gitlab-backup 사용을 안내합니다. 이 명령은 두 개의 하위 명령 옵션을 가진 매우 단순한 인터페이스를 제공합니다.

# To create a backup
sudo gitlab-backup create
# This corresponds to gitlab-rake gitlab:backup:create

# To restore a previously-captured backup
sudo gitlab-backup restore BACKUP=<backup_id>
# This corresponds to gitlab-rake gitlab:backup:restore BACKUP=<backup_id>

이 명령은 실제로는 GitLab Rails 애플리케이션에 정의된 핵심 백업·복원 Rake 태스크를 감싸는 셸 스크립트입니다. Rake 태스크는 일반적으로 환경 변수로 파라미터와 런타임 구성을 정의하며, 이 명령은 호출 시 의미 있는 환경 설정을 Rake 프로세스로 전달합니다. 다만 주된 백업 생성과 복원 작업은 Rake 태스크 안에 정의되어 있으며, 다음 절에서 더 자세히 다룹니다.

Rake 태스크#

현재 GitLab Rails 애플리케이션은 관리자가 애플리케이션 데이터를 백업하고 이후 복원하는 주된 수단으로 여러 Rake 태스크를 제공합니다.

특정 시점 백업 아카이브 생성#

sudo gitlab-rake gitlab:backup:create [env-overrides]

백업 생성 Rake 태스크의 목표는 실행 시점의 모든 GitLab 애플리케이션 데이터 계열의 상태를 담아 두는 것입니다. 일반적으로 정상 호출되면 생성 태스크는 백업 아카이브 tarball 파일을 만듭니다.

아카이브 tarball의 내용과 형식은 /etc/gitlab/gitlab.rb의 시스템 전역 구성 설정이나 호출 시점에 지정한 환경 변수에 따라 크게 달라질 수 있습니다. 또한 이러한 설정에 따라 백업이 생성 후 저장되는 위치나 복원 시 백업을 찾을 위치가 결정되기도 합니다. 일반적인 1K 설치보다 데이터 규모가 훨씬 큰 설치에서 이러한 작업을 수행할 때 성능을 조정하는 옵션도 있습니다.

기본 백업 생성 절차#

사용자가 백업 생성 Rake 태스크를 실행하면 다음과 같은 상위 수준 단계가 순서대로 수행됩니다.

1. 모든 애플리케이션 백업 데이터와 메타데이터를 저장할 임시 디렉터리를 만듭니다.

2. 애플리케이션이 사용하는 각 PostgreSQL 데이터베이스를 아카이브의 db 하위 디렉터리에 SQL 파일로 덤프합니다. 이 작업은 대개 주요 데이터베이스마다 pg_dump를 호출해 수행합니다. 생성된 각 .sql 파일은 gzip으로 추가 압축합니다.

3. Gitaly를 통해 애플리케이션의 각 Git 리포지터리에 번들 내보내기를 요청합니다. 이 데이터는 모두 아카이브의 repositories 디렉터리에 보관합니다. 프로젝트에 연결된 "wiki" 나 "design" 데이터도 연관 Git 리포지터리로 저장되므로 함께 포함됩니다.

4. 남은 "blob" 성격의 데이터 기능에서는 각 blob 이 디렉터리의 파일 하나에 대응합니다. 따라서 바이너리 데이터 기능마다 각 blob 항목을 아카이브 내 임시 디렉터리의 이름 있는 파일로 복사합니다. 모든 데이터를 복사한 뒤 해당 디렉터리를 압축하고 직렬화해 아카이브 안에 포함되는 .tar.gz 파일로 만듭니다. 이 작업은 다음 기능마다 수행합니다.

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

5. 백업 작업의 파라미터와 상태를 아카이브 디렉터리 최상위의 backup_information.yml YAML 파일에 기록합니다.

6. 임시 아카이브 디렉터리를 하나의 .tar tarball 파일로 직렬화합니다.

7. tarball 파일을 최종 저장 위치로 옮깁니다. 시스템 구성과 파라미터에 따라 생성 태스크를 실행한 머신의 디렉터리일 수도 있고, S3 나 Google Storage 같은 클라우드 스토리지 서비스의 버킷일 수도 있습니다.

여러 구성 값과 환경 파라미터가 이 일반 절차를 바꿀 수 있습니다. 해당 파라미터는 다음 절에서 다룹니다.

백업 생성 커스터마이징#

일반적으로 /etc/gitlab/gitlab.rb에 있는 시스템 전역 GitLab 구성 파일에서는 백업 생성이나 복원 호출에 적용되는 여러 표준 파라미터를 설정할 수 있습니다. 특히 다음 표는 백업 작업 실행에 영향을 주는, gitlab_rails 구성 객체에 설정할 수 있는 키를 보여 줍니다.

또한 백업 생성이나 복원 작업을 실행할 때마다 환경 변수를 설정해 백업 알고리즘, 데이터 접근 위치, 아카이브 저장 형식을 변경할 수 있습니다. 백업 아카이브 생성 작업에서 Rake 태스크는 다음 환경 변수 설정을 지원합니다.

특정 시점 백업 아카이브 복원#

sudo gitlab-rake gitlab:backup:restore BACKUP=<backup_id> [env-overrides]

이전에 백업 생성 태스크를 정상적으로 실행했다면 애플리케이션 데이터 상태를 대략 그 시점으로 되돌리는 데 사용할 아카이브 tarball 파일이 있습니다. 이러한 아카이브 파일은 시스템 구성에 따라 로컬 시스템의 특정 디렉터리나 클라우드 오브젝트 스토리지 버킷에 저장됩니다. 백업이 확보된 것을 확인한 관리자는 위에 제시한 gitlab-rake 명령으로 특정 백업의 복원을 요청할 수 있으며, 여기서 <backup_id>는 백업 tarball의 기본 파일 이름을 가리킵니다.

복원 작업을 실행하면 현재 애플리케이션 데이터 상태가 모두 사라집니다. 따라서 Rake 태스크는 진행 전에 이 파괴적인 작업을 사용자에게 확인받기 위해 잠시 멈춥니다.

기본 백업 복원 절차#

사용자가 백업 복원 Rake 태스크를 실행하면 생성 과정의 단계를 거울처럼 되짚는 일련의 단계가 수행됩니다. 순서는 다음과 같습니다.

1. 복원 중 작업 디렉터리로 사용할 임시 디렉터리를 만듭니다

2. 대상 아카이브 tarball의 사본을 가져와 작업 디렉터리 안에 내용을 풉니다

3. 아카이브 데이터를 복원할 수 있는지 검증합니다:

   1. backup_information.yml 파일이 있으면 그 파일에서 백업 메타데이터를 읽습니다.
   2. 백업 시점의 GitLab 애플리케이션 버전이 현재 애플리케이션 버전과 일치하는지 확인합니다.
   3. 이 파일 중 하나라도 없거나 형식이 잘못되었거나 버전이 일치하지 않으면 복원 과정 전체를 중단합니다.

4. 복원을 진행하기 전에 현재 GitLab 데이터를 모두 삭제해도 되는지 사용자에게 확인합니다.

5. 알려진 애플리케이션 데이터베이스에 대응하는 각 .sql.gz 파일을 읽어 압축을 풉니다. SQL 내용을 실행해 각 데이터베이스의 전체 상태를 덮어씁니다.

6. repositories 아카이브 디렉터리에 저장된 모든 리포지터리 번들 데이터를 가져옵니다. 저장된 번들 데이터를 사용해 Gitaly 서비스와 함께 각 리포지터리를 예상 저장 위치로 복원합니다. 최상위 아카이브 디렉터리에서 대상 기능에 대응하는 .tar.gz 파일을 찾습니다. 각 기능 tarball의 압축을 풀고 바이너리 파일 내용을 읽어 시스템에 구성된 적절한 blob 스토리지로 복사합니다. 이 작업은 다음 기능마다 수행합니다.

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

7. GitLab Shell 설정 태스크를 실행해 SSH 접근을 다시 구성하고 authorized_keys 파일을 다시 만듭니다.

8. 캐시 데이터를 모두 지웁니다.

백업 생성 작업과 마찬가지로, 복원 태스크의 수행 방식을 바꿀 수 있는 구성 파일 값과 환경 변수가 많이 있습니다.