GitLab은 다양한 설치 유형과 호스팅 아키텍처에 걸쳐 애플리케이션 백업을 생성하는 방법에 대한 권장 사항을 제공합니다. 특정 시점(point-in-time)의 애플리케이션 백업을 생성하는 간단한 도구와, 복잡한 클라우드 기반 설치 백업을 처리하는 방법에 대한 전문 문서를 제공합니다.

백업 및 복원은 주로 Linux Package 및 Docker 설치 방법과 함께 제공되는 gitlab-backup 도구를 기반으로 합니다.

쿠버네티스 설치에만 제공되는 추가 도구 backup-utility가 있으며, 이는 다른 구현 방식을 사용합니다.

gitlab-backup 도구#

현재 GitLab 문서에서 백업 생성 및 복원 수행에 관한 내용은 Omnibus로 생성된 시스템 패키지에 내장된 특수 명령어인 gitlab-backup을 사용하도록 안내합니다. 이 명령어는 두 가지 서브커맨드 옵션을 갖는 매우 단순한 인터페이스를 제공합니다:

# 백업을 생성하려면
sudo gitlab-backup create
# 이는 gitlab-rake gitlab:backup:create에 해당합니다

# 이전에 캡처한 백업을 복원하려면
sudo gitlab-backup restore BACKUP=<backup_id>
# 이는 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 태스크를 실행하면 다음과 같은 높은 수준의 단계 순서가 실행됩니다:

• 모든 애플리케이션 백업 데이터와 메타데이터를 저장하기 위한 임시 디렉터리를 생성합니다.

• 아카이브의 db 서브디렉터리에 있는 SQL 파일에서 애플리케이션이 사용하는 각 PostgreSQL 데이터베이스를 덤프합니다. 이는 일반적으로 각 중요한 데이터베이스에서 pg_dump를 호출하여 수행됩니다. 생성된 각 .sql 파일은 gzip으로 추가 압축됩니다.

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

• 나머지 각 "blob" 지향 데이터 기능에 대해 각 blob은 디렉터리의 파일에 해당합니다. 따라서 각 바이너리 데이터 기능에 대해 각 blob 항목을 아카이브의 임시 디렉터리에 있는 명명된 파일로 복사합니다. 모든 데이터가 복사되면 디렉터리를 압축하여 아카이브 자체에 포함된 .tar.gz 파일로 직렬화합니다. 이 작업은 다음 각 기능에 대해 수행됩니다:

  artifacts

  • builds

  • ci_secure_files

  • external_diffs

  • lfs

  • packages

  • pages

  • registry

  • uploads

  • terraform_state

• 아카이브 디렉터리의 최상위 레벨에 있는 backup_information.yml이라는 YAML 파일에 백업 작업의 매개변수와 상태를 기록합니다.

• 임시 아카이브 디렉터리를 단일 .tar tarball 파일로 직렬화합니다.

• 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 태스크를 실행하면 생성 프로세스 중에 수행된 단계를 미러링하는 일련의 단계가 실행됩니다. 이 순서는 다음과 같이 설명됩니다:

• 복원 중 작업 디렉터리로 사용할 임시 디렉터리를 생성합니다.

• 타깃 아카이브 tarball의 복사본을 가져와 작업 디렉터리 내에 콘텐츠를 압축 해제합니다.

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

  backup_information.yml 파일이 있으면 해당 파일에서 백업 메타데이터를 읽습니다.

  • 백업 시점의 GitLab 애플리케이션 버전이 현재 애플리케이션 버전과 일치하는지 확인합니다.

  • 이러한 파일 중 하나라도 존재하지 않거나 잘못된 형식이거나 버전이 일치하지 않으면 전체 복원 프로세스에서 오류를 발생시킵니다.

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

• 알려진 애플리케이션 데이터베이스에 해당하는 각 .sql.gz 파일을 읽고 압축 해제합니다. SQL 콘텐츠를 실행하여 각 데이터베이스의 전체 상태를 덮어씁니다.

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

  uploads

  • builds

  • artifacts

  • pages

  • lfs

  • terraform_state

  • registry

  • packages

  • ci_secure_files

• GitLab Shell 설정 태스크를 실행하여 SSH 접근을 재구성하고 authorized_keys 파일을 다시 빌드합니다.

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

백업 생성 작업과 마찬가지로 복원 태스크 수행 방식을 변경할 수 있는 구성 파일 값과 환경 변수가 다양하게 있습니다.