간단한 백업 절차
백업 확장
어떤 데이터를 백업해야 하나요?
커맨드 라인 인터페이스
대체 백업 전략
- 저장소 데이터를 별도로 백업하기
  - 쓰기 방지 및 Git 저장소 데이터 복사
  - 저장소를 읽기 전용으로 마킹하여 온라인 백업 생성하기 (실험적)

GitLab 백업

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

GitLab을 백업하는 정확한 절차는 여러 요인에 따라 달라집니다. 특정 배포의 사용 및 구성에 따라 존재하는 데이터의 종류, 위치 및 양이 결정됩니다. 이러한 요인은 백업 수행 방법, 저장 방법 및 복원 방법에 대한 옵션에 영향을 미칩니다.

간단한 백업 절차

대략적인 지침으로, 100GB 미만의 데이터를 가진 1k 참조 아키텍처를 사용하고 있다면, 다음 단계를 따르세요:

백업 명령을 실행합니다.
해당하는 경우 객체 저장소를 백업합니다.
구성 파일을 수동으로 백업합니다.

백업 확장

GitLab 데이터의 양이 증가함에 따라, 백업 명령의 실행 시간이 길어집니다. 백업 옵션으로는 Git 리포지토리를 동시에 백업하기 및 증분 리포지토리 백업 등이 있어 실행 시간을 줄이는 데 도움이 됩니다. 어느 시점부터 백업 명령만으로는 비효율적일 수 있습니다. 예를 들어, 24시간 이상 걸릴 수 있습니다.

일부 경우에는 백업을 확장할 수 있도록 아키텍처 변경이 필요할 수 있습니다. GitLab 참조 아키텍처를 사용 중이라면, 대형 참조 아키텍처 백업 및 복원을 참조하세요.

자세한 정보는 대체 백업 전략을 참조하세요.

PostgreSQL 데이터베이스

가장 간단한 경우, GitLab은 모든 GitLab 서비스와 같은 VM에 있는 하나의 PostgreSQL 서버에 하나의 PostgreSQL 데이터베이스를 가지고 있습니다. 그러나 구성에 따라 GitLab은 여러 PostgreSQL 데이터베이스를 여러 PostgreSQL 서버에서 사용할 수 있습니다.

일반적으로 이 데이터는 웹 인터페이스에서 생성된 대부분의 사용자 콘텐츠(예: 이슈 및 병합 요청 내용, 댓글, 권한 및 자격 증명)의 단일 진실 원천입니다.

PostgreSQL은 HTML로 렌더링된 Markdown과 같은 일부 캐시된 데이터도 보유하며, 기본적으로 병합 요청 diff를 포함합니다. 그러나 병합 요청 diff는 파일 시스템이나 객체 저장소로 오프로드되도록 구성할 수도 있습니다. Blob을 참조하세요.

Gitaly Cluster의 Praefect 서비스는 Gitaly 노드를 관리하기 위해 단일 진실 원천으로 PostgreSQL 데이터베이스를 사용합니다.

일반적인 PostgreSQL 유틸리티인 pg_dump는 PostgreSQL 데이터베이스를 복원하는 데 사용할 수 있는 백업 파일을 생성합니다. 백업 명령은 이 유틸리티를 내부적으로 사용합니다.

불행히도, 데이터베이스가 커질수록 pg_dump가 실행되는 시간이 길어집니다. 상황에 따라 이 기간은 비효율적이 됩니다(예: 며칠). 데이터베이스가 100GB를 초과하는 경우, pg_dump와 백업 명령은 사용할 수 없게 됩니다. 자세한 정보는 대체 백업 전략을 참조하세요.

Git 저장소

GitLab 인스턴스는 하나 이상의 리포지토리 샤드를 가질 수 있습니다. 각 샤드는 로컬에 저장된 Git 저장소에 대한 액세스 및 작업을 허용하는 Gitaly 인스턴스 또는 Gitaly 클러스터입니다. Gitaly는 다음과 같은 머신에서 실행될 수 있습니다:

단일 디스크로.
RAID 배열과 같이 단일 마운트 포인트에 여러 디스크가 마운트된 상태로.
LVM을 사용하여.

각 프로젝트는 최대 3개의 서로 다른 저장소를 가질 수 있습니다:

소스 코드가 저장되는 프로젝트 저장소.
위키 콘텐츠가 저장되는 위키 저장소.
디자인 자산이 색인화되는 디자인 저장소(자산은 실제로 LFS에 존재).

모두 동일한 샤드에 존재하며, 위키 및 디자인 저장소의 경우 -wiki 및 -design 접미사로 동일한 기본 이름을 공유합니다.

개인 및 프로젝트 스니펫과 그룹 위키 콘텐츠는 Git 저장소에 저장됩니다.

프로젝트 포크는 풀 저장소를 사용하여 GitLab 사이트에서 중복 제거됩니다.

백업 명령은 각 저장소에 대해 Git 번들을 생성하고 이를 모두 tarring합니다. 이로 인해 풀 저장소 데이터가 모든 포크에 중복됩니다. 우리의 테스트에서 100GB의 Git 저장소를 백업하고 S3에 업로드하는 데 2시간 넘게 걸렸습니다. 약 400GB의 Git 데이터를 통해 백업 명령은 정기적인 백업에 적합하지 않을 수 있습니다. 추가 정보는 대체 백업 전략을 참조하세요.

Blob

GitLab은 문제 첨부 파일이나 LFS 객체와 같은 blob(또는 파일)을 다음 중 하나에 저장합니다:

특정 위치의 파일 시스템.
오브젝트 스토리지 솔루션. 오브젝트 스토리지 솔루션은 다음과 같습니다:
- Amazon S3 및 Google Cloud Storage와 같은 클라우드 기반.
- 직접 호스팅(예: MinIO).
- Object Storage 호환 API를 제공하는 Storage Appliance.

오브젝트 스토리지

백업 명령은 파일 시스템에 저장되지 않은 blob를 백업하지 않습니다. 오브젝트 스토리지를 사용하는 경우, 오브젝트 스토리지 공급자와 함께 백업을 활성화해야 합니다. 예를 들어, 다음을 참조하세요:

컨테이너 레지스트리

GitLab 컨테이너 레지스트리 저장소는 다음 중 하나에서 구성할 수 있습니다:

특정 위치의 파일 시스템.
오브젝트 스토리지 솔루션. 오브젝트 스토리지 솔루션은 다음과 같습니다:
- Amazon S3 및 Google Cloud Storage와 같은 클라우드 기반.
- 직접 호스팅(예: MinIO).
- Object Storage 호환 API를 제공하는 Storage Appliance.

백업 명령은 오브젝트 스토리지에 저장된 레지스트리 데이터를 백업하지 않습니다.

구성 파일 저장

경고:
백업 Rake 작업 GitLab이 제공하는 작업은 구성을 저장하지 않습니다. 이의 주요 이유는 데이터베이스에 2단계 인증 및 CI/CD _보안 변수_에 대한 암호화된 정보를 포함한 항목이 있기 때문입니다. 암호화된 정보를 그 키와 동일한 위치에 저장하는 것은 암호화의 목적을 무색하게 만듭니다. 예를 들어, 비밀 파일에는 데이터베이스 암호화 키가 포함되어 있습니다. 이를 잃어버리면 GitLab 애플리케이션은 데이터베이스의 암호화된 값을 복호화할 수 없습니다.

경고:
비밀 파일은 업그레이드 후 변경될 수 있습니다.

구성 디렉터리를 백업해야 합니다. 최소한 다음을 백업해야 합니다:

리눅스 패키지

/etc/gitlab/gitlab-secrets.json
/etc/gitlab/gitlab.rb

자세한 내용은 백업 및 복원 리눅스 패키지(Omnibus) 구성을 참조하세요.

자체 컴파일

/home/git/gitlab/config/secrets.yml
/home/git/gitlab/config/gitlab.yml

도커

구성 파일이 저장된 볼륨을 백업합니다. 문서에 따라 GitLab 컨테이너를 생성한 경우 /srv/gitlab/config 디렉터리에 있어야 합니다.

GitLab 헬름 차트

비밀 백업 지침을 따르세요.

모든 TLS 키 및 인증서(/etc/gitlab/ssl, /etc/gitlab/trusted-certs)를 백업하고, 전체 머신 복원을 수행해야 하는 경우 경고가 발생하지 않도록 SSH 호스트 키를 백업하는 것도 고려해야 합니다.

비밀 파일이 잃어버린 경우의 가능성이 낮지만, 비밀 파일이 분실된 경우를 참조하세요.

기타 데이터

GitLab은 Redis를 캐시 저장소로 사용하며 백그라운드 작업 시스템인 Sidekiq를 위한 지속적인 데이터를 보관합니다. 제공된 백업 명령어는 Redis 데이터를 백업하지 않습니다. 이는 백업 명령어로 일관된 백업을 수행하기 위해서는 보류 중이거나 실행 중인 백그라운드 작업이 없어야 함을 의미합니다. Redis를 수동으로 백업하는 것이 가능합니다.

Elasticsearch는 고급 검색을 위한 선택적 데이터베이스입니다. 이는 소스 코드 수준 및 이슈, 병합 요청 및 토론에서 사용자 생성 콘텐츠의 검색을 개선할 수 있습니다. 백업 명령어는 Elasticsearch 데이터를 백업하지 않습니다. Elasticsearch 데이터는 복원 후 PostgreSQL 데이터에서 재생성할 수 있습니다. Elasticsearch를 수동으로 백업하는 것이 가능합니다.

커맨드 라인 인터페이스

GitLab은 다음을 포함하여 전체 인스턴스를 백업하는 커맨드 라인 인터페이스를 제공합니다:

데이터베이스
첨부 파일
Git 리포지토리 데이터
CI/CD 작업 출력 로그
CI/CD 작업 아티팩트
LFS 객체
Terraform 상태
컨테이너 레지스트리 이미지
GitLab Pages 콘텐츠
패키지
스니펫
그룹 위키
프로젝트 수준의 보안 파일 (도입됨 GitLab 16.1에서)
외부 병합 요청 diff (도입됨 GitLab 17.1에서)

백업에는 포함되지 않습니다:

Mattermost 데이터
Redis (따라서 Sidekiq 작업 포함)
리눅스 패키지(Omnibus) / Docker / 수동 컴파일 설치의 객체 저장소
전역 서버 후크
파일 후크

경고:
GitLab은 구성 파일(/etc/gitlab), TLS 키 및 인증서 또는 시스템 파일을 백업하지 않습니다. 구성 파일 저장에 대해 읽어보는 것이 강력히 권장됩니다.

요구 사항

백업 및 복원이 가능하도록 하려면 시스템에 Rsync가 설치되어 있는지 확인하십시오. GitLab을 설치한 경우:

리눅스 패키지를 사용한 경우, Rsync가 이미 설치되어 있습니다.
수동으로 컴파일한 경우, rsync가 설치되어 있는지 확인하십시오. Rsync가 설치되어 있지 않으면 설치하십시오. 예를 들어:
```
# Debian/Ubuntu
sudo apt-get install rsync

# RHEL/CentOS
sudo yum install rsync
```

백업 명령어

경고:
백업 명령어는 리눅스 패키지(Omnibus) / Docker / 수동 컴파일 설치의 객체 저장소에서 항목을 백업하지 않습니다.

경고:
백업 명령어는 성능상의 이유로 또는 Patroni 클러스터와 함께 사용할 때 PgBouncer를 사용하는 경우 추가 매개변수가 필요합니다.

경고:
GitLab 15.5.0 이전의 백업 명령어는 다른 백업이 이미 실행 중인지 확인하지 않습니다. 이슈 362593에 설명된 대로, 새로운 백업을 시작하기 전에 모든 백업이 완료되었는지 확인하는 것을 강력히 권장합니다.

참고:
백업은 정확히 동일한 버전 및 유형(CE/EE)의 GitLab에만 복원할 수 있습니다.

리눅스 패키지 (Omnibus)

sudo gitlab-backup create

헬름 차트 (Kubernetes)

kubectl을 사용하여 GitLab 도구 상자 포드에서 backup-utility 스크립트를 실행하여 백업 작업을 실행합니다. 자세한 내용은 차트 백업 문서를 참조하십시오.

도커

호스트에서 백업을 실행합니다.

docker exec -t <컨테이너 이름> gitlab-backup create

수동 컴파일

sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production

여러 노드로 GitLab을 배포한 경우 백업 명령어를 실행할 노드를 선택해야 합니다. 지정된 노드가 다음을 충족하는지 확인해야 합니다:

지속성이 있으며 자동 확장에 영향을 받지 않아야 합니다.
GitLab Rails 애플리케이션이 이미 설치되어 있어야 합니다. Puma 또는 Sidekiq가 실행 중인 경우, Rails는 설치됩니다.
백업 파일을 생성할 수 있는 충분한 저장소와 메모리를 갖추어야 합니다.

예시 출력:

데이터베이스 테이블 덤프 중:
- 이벤트 테이블 덤프 중... [완료]
- 이슈 테이블 덤프 중... [완료]
- 키 테이블 덤프 중... [완료]
- 병합 요청 테이블 덤프 중... [완료]
- 마일스톤 테이블 덤프 중... [완료]
- 네임스페이스 테이블 덤프 중... [완료]
- 노트 테이블 덤프 중... [완료]
- 프로젝트 테이블 덤프 중... [완료]
- 보호된 브랜치 테이블 덤프 중... [완료]
- 스키마 마이그레이션 테이블 덤프 중... [완료]
- 서비스 테이블 덤프 중... [완료]
- 스니펫 테이블 덤프 중... [완료]
- 태그 지정 테이블 덤프 중... [완료]
- 태그 테이블 덤프 중... [완료]
- 사용자 테이블 덤프 중... [완료]
- 사용자 프로젝트 테이블 덤프 중... [완료]
- 웹 훅 테이블 덤프 중... [완료]
- 위키 테이블 덤프 중... [완료]
리포지토리 덤프 중:
- 리포지토리 abcd 덤프 중... [완료]
백업 아카이브 생성: <backup-id>_gitlab_backup.tar [완료]
tmp 디렉터리 삭제 중...[완료]
오래된 백업 삭제 중... [건너뜀]

백업 프로세스에 대한 자세한 정보는 백업 아카이브 프로세스를 참조하십시오.

백업 옵션

GitLab이 제공하는 명령줄 도구는 인스턴스를 백업하기 위해 더 많은 옵션을 수용할 수 있습니다.

백업 전략 옵션

기본 백업 전략은 본질적으로 각각의 데이터 위치에서 백업으로 데이터를 스트리밍하는 것입니다. 이는 리눅스 명령어 tar와 gzip을 사용합니다. 대부분의 경우 잘 작동하지만 데이터가 급격하게 변할 때 문제를 일으킬 수 있습니다.

데이터가 tar가 읽는 동안 변경되면 file changed as we read it라는 오류가 발생하여 백업 프로세스가 실패할 수 있습니다. 이 경우 copy라는 백업 전략을 사용할 수 있습니다. 이 전략은 tar와 gzip을 호출하기 전에 데이터 파일을 임시 위치로 복사하여 오류를 피합니다.

부작용으로 백업 프로세스는 최대 1X의 추가 디스크 공간을 차지합니다. 프로세스는 각 단계에서 임시 파일을 청소하기 위해 최선을 다하지만, 이는 대규모 설치의 경우 상당한 변경이 될 수 있습니다.

기본 스트리밍 전략 대신 copy 전략을 사용하려면 Rake 작업 명령어에서 STRATEGY=copy를 지정하십시오. 예를 들어:

sudo gitlab-backup create STRATEGY=copy

백업 파일 이름

경고: 사용자 정의 백업 파일 이름을 사용하는 경우 백업의 사용 기간을 제한할 수 없습니다. 로컬 파일의 백업 수명 제한하기.

백업 파일은 특정 기본값에 따라 파일 이름이 생성됩니다. 하지만 BACKUP 환경 변수를 설정하여 파일 이름의 <backup-id> 부분을 재정의할 수 있습니다. 예를 들어:

sudo gitlab-backup create BACKUP=dump

결과로 생성된 파일 이름은 dump_gitlab_backup.tar입니다. 이는 rsync와 증분 백업을 사용하는 시스템에 유용하며, 속도가 상당히 빨라집니다.

백업 압축

기본적으로 Gzip 빠른 압축이 다음의 백업 중에 적용됩니다:

PostgreSQL 데이터베이스 덤프.
블롭, 예를 들어 업로드, 작업 아티팩트, 외부 병합 요청 차이.

기본 명령은 gzip -c -1입니다. 이 명령을 COMPRESS_CMD로 재정의할 수 있습니다. 마찬가지로, DECOMPRESS_CMD로 압축 해제 명령을 재정의할 수 있습니다.

주의사항:

압축 명령은 파이프라인에서 사용되므로 귀하의 커스텀 명령은 stdout에 출력을 해야 합니다.
GitLab에 패키지되지 않은 명령을 지정하는 경우, 직접 설치해야 합니다.
결과 파일 이름은 여전히 .gz로 끝납니다.
복원 중에 사용되는 기본 압축 해제 명령은 gzip -cd입니다. 따라서 압축 명령을 gzip -cd로 압축 해제할 수 없는 형식으로 재정의하면, 복원 중에 압축 해제 명령을 재정의해야 합니다.
백업 명령 뒤에 환경 변수를 배치하지 마세요. 예를 들어, gitlab-backup create COMPRESS_CMD="pigz -c --best"는 의도한 대로 작동하지 않습니다.

기본 압축: 가장 빠른 방법으로 Gzip

gitlab-backup create

가장 느린 방법으로 Gzip

COMPRESS_CMD="gzip -c --best" gitlab-backup create

백업에 gzip가 사용된 경우, 복원할 때는 어떤 옵션도 필요하지 않습니다:

gitlab-backup restore

압축 없음

백업 대상에 자동 압축 기능이 내장된 경우 압축을 건너뛰고 싶을 수 있습니다.

tee 명령은 stdin을 stdout으로 파이프합니다.

COMPRESS_CMD=tee gitlab-backup create

복원 시:

DECOMPRESS_CMD=tee gitlab-backup restore

`pigz`를 사용한 병렬 압축

경고: COMPRESS_CMD 및 DECOMPRESS_CMD를 사용하여 기본 Gzip 압축 라이브러리를 재정의하는 것을 지원하지만, 기본 옵션으로 기본 Gzip 라이브러리를 정기적으로 테스트합니다. 백업의 유효성을 테스트하고 검증하는 것은 귀하의 책임입니다. 압축 명령을 재정의하든 관계없이 일반적으로 백업에 대한 모범 사례로 이를 강력히 권장합니다. 다른 압축 라이브러리에서 문제를 발견하면 기본값으로 되돌려야 합니다. 대체 라이브러리의 문제 해결 및 수정은 GitLab의 우선 순위가 낮습니다.

참고: pigz는 GitLab Linux 패키지에 포함되어 있지 않습니다. 직접 설치해야 합니다.

4개의 프로세스를 사용하여 pigz로 백업을 압축하는 예:

COMPRESS_CMD="pigz --compress --stdout --fast --processes=4" sudo gitlab-backup create

pigz는 gzip 형식으로 압축하므로 pigz로 압축된 백업을 해제하는 데 pigz를 사용할 필요는 없습니다. 그러나 여전히 gzip보다 성능상의 이점이 있을 수 있습니다. pigz로 백업을 해제하는 예:

DECOMPRESS_CMD="pigz --decompress --stdout" sudo gitlab-backup restore

`zstd`를 사용한 병렬 압축

참고: zstd는 GitLab Linux 패키지에 포함되어 있지 않습니다. 직접 설치해야 합니다.

4개의 스레드를 사용하여 zstd로 백업을 압축하는 예:

COMPRESS_CMD="zstd --compress --stdout --fast --threads=4" sudo gitlab-backup create

zstd로 백업을 해제하는 예:

DECOMPRESS_CMD="zstd --decompress --stdout" sudo gitlab-backup restore

전송 가능한 아카이브 확인

생성된 아카이브가 rsync로 전송 가능한지 확인하려면 GZIP_RSYNCABLE=yes 옵션을 설정할 수 있습니다. 이는 gzip에 --rsyncable 옵션을 설정하는 것으로, 백업 파일 이름 옵션 설정과 함께 사용할 때만 유용합니다.

gzip의 --rsyncable 옵션이 모든 배포판에서 사용 가능하다고 보장되지 않습니다. 배포판에서 사용 가능한지 확인하려면 gzip --help를 실행하거나 매뉴얼 페이지를 참조하세요.

sudo gitlab-backup create BACKUP=dump GZIP_RSYNCABLE=yes

백업에서 특정 데이터 제외

설치 유형에 따라 백업 생성 시 조금 다른 구성 요소를 건너뛸 수 있습니다.

Linux 패키지 (Omnibus) / Docker / 셀프 컴파일

db (데이터베이스)
repositories (위키를 포함한 Git 저장소 데이터)
uploads (첨부 파일)
builds (CI 작업 출력 로그)
artifacts (CI 작업 아티팩트)
pages (페이지 콘텐츠)
lfs (LFS 객체)
terraform_state (Terraform 상태)
registry (컨테이너 레지스트리 이미지)
packages (패키지)
ci_secure_files (프로젝트 수준의 보안 파일)
external_diffs (외부 병합 요청 차이)

Helm 차트 (Kubernetes)

db (데이터베이스)
repositories (위키를 포함한 Git 저장소 데이터)
uploads (첨부 파일)
artifacts (CI 작업 아티팩트 및 출력 로그)
pages (페이지 콘텐츠)
lfs (LFS 객체)
terraform_state (Terraform 상태)
registry (컨테이너 레지스트리 이미지)
packages (패키지 레지스트리)
ci_secure_files (프로젝트 수준의 보안 파일)
external_diffs (병합 요청 차이)

Linux 패키지 (Omnibus)

sudo gitlab-backup create SKIP=db,uploads

Helm 차트 (Kubernetes)

구성 요소 건너뛰기에서 차트 백업 문서를 참조하세요.

셀프 컴파일

sudo -u git -H bundle exec rake gitlab:backup:create SKIP=db,uploads RAILS_ENV=production

SKIP=는 다음을 위해서도 사용됩니다:

tar 파일 생성을 건너뛰기 (SKIP=tar).
원격 스토리지에 백업 업로드 건너뛰기 (SKIP=remote).

tar 생성 건너뛰기

참고:

객체 저장소를 사용하여 백업할 때 tar 생성을 건너뛸 수 없습니다.

백업 생성의 마지막 단계는 모든 부분을 포함하는 .tar 파일의 생성입니다. 경우에 따라 .tar 파일을 생성하는 것은 불필요한 노력일 수 있으며, 심지어 직접적으로 해롭기까지 하므로, SKIP 환경 변수에 tar를 추가하여 이 단계를 건너뛸 수 있습니다. 사용 사례 예시:

백업이 다른 백업 소프트웨어에 의해 수집될 때.
매번 백업을 추출할 필요를 피함으로써 증가 백업 속도를 높일 때. (이 경우 PREVIOUS_BACKUP 및 BACKUP이 지정되지 않아야 하며, 그렇지 않으면 지정된 백업이 추출되지만, 최종적으로 .tar 파일이 생성되지 않습니다.)

tar를 SKIP 변수에 추가하면, 백업을 포함하는 파일 및 디렉토리가 중간 파일에 사용되는 디렉토리에 남습니다. 이러한 파일은 새로운 백업이 생성될 때 덮어씌워지므로, 다른 곳에 복사해야 합니다. 시스템에 백업은 하나만 존재할 수 있습니다.

Linux 패키지 (Omnibus)

sudo gitlab-backup create SKIP=tar

자체 컴파일

sudo -u git -H bundle exec rake gitlab:backup:create SKIP=tar RAILS_ENV=production

서버 측 저장소 백업 생성

GitLab 16.3에서 gitlab-backup에 도입됨.

GitLab 16.6에서 도입된 특정 백업을 복원하기 위한 gitlab-backup의 서버 측 지원.

GitLab 16.6에서 도입된 증분 백업 생성을 위한 gitlab-backup의 서버 측 지원.

GitLab 17.0에서 도입된 backup-utility의 서버 측 지원.

대용량 저장소 백업을 백업 아카이브에 저장하는 대신, 저장소 백업은 각 저장소를 호스팅하는 Gitaly 노드가 백업을 생성하고 이를 객체 저장소로 스트리밍하도록 구성할 수 있습니다. 이는 백업 생성 및 복원에 필요한 네트워크 자원을 줄이는 데 도움이 됩니다.

Gitaly에서 서버 측 백업 대상 구성하기.
저장소의 서버 측 옵션을 사용하여 백업을 생성합니다. 다음 예를 참조하세요.

Linux 패키지 (Omnibus)

sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true

자체 컴파일

sudo -u git -H bundle exec rake gitlab:backup:create REPOSITORIES_SERVER_SIDE=true

Helm 차트 (Kubernetes)

kubectl exec <Toolbox pod name> -it -- backup-utility --repositories-server-side

cron 기반 백업을 사용하는 경우, 추가 인자에 --repositories-server-side 플래그를 추가하세요.

Git 리포지토리 동시 백업

다수의 리포지토리 저장소를 사용할 때,

리포지토리는 CPU 시간을 최대한 활용하기 위해 동시 백업 또는 복원이 가능합니다.

다음 변수들은 Rake 작업의 기본 동작을 수정하는 데 사용할 수 있습니다:

GITLAB_BACKUP_MAX_CONCURRENCY: 동시에 백업할 수 있는 프로젝트의 최대 수. 기본값은 논리 CPU의 수입니다.
GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY: 각 저장소에서 동시에 백업할 수 있는 프로젝트의 최대 수. 이로 인해 리포지토리 백업이 저장소에 분산될 수 있습니다. 기본값은 2입니다.

예를 들어, 4개의 리포지토리 저장소가 있을 때:

Linux 패키지 (Omnibus)

sudo gitlab-backup create GITLAB_BACKUP_MAX_CONCURRENCY=4 GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY=1

셀프 컴파일

sudo -u git -H bundle exec rake gitlab:backup:create GITLAB_BACKUP_MAX_CONCURRENCY=4 GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY=1

증분 리포지토리 백업

PREVIOUS_BACKUP 옵션은 GitLab 15.0에서 도입됨.

서버 측의 증분 백업 생성 지원은 GitLab 16.6에서 도입됨.

셀프 관리 GitLab에서는 기본적으로 이 기능이 제공됩니다. 기능을 숨기려면 관리자가 incremental_repository_backup이라는 기능 플래그를 비활성화할 수 있습니다.

GitLab.com 및 GitLab Dedicated에서는 이 기능이 제공되지 않습니다.

오직 리포지토리만이 증분 백업을 지원합니다. 따라서 INCREMENTAL=yes를 사용하면 작업이 자체 포함된 백업 tar 아카이브를 생성합니다. 이는 리포지토리를 제외한 모든 하위 작업이 여전히 전체 백업을 생성하기 때문입니다(기존 전체 백업을 덮어씁니다).

모든 하위 작업에 대한 증분 백업 지원 요청은 이슈 19256를 참조하세요.

증분 리포지토리 백업은 마지막 백업 이후의 변경 사항만 백업 번들에 포장하므로 전체 리포지토리 백업보다 빠를 수 있습니다.

증분 백업 아카이브는 서로 연결되지 않습니다: 각 아카이브는 인스턴스의 자체 포함된 백업입니다.

증분 백업을 생성하기 위해서는 기존 백업이 있어야 합니다.

PREVIOUS_BACKUP=<backup-id> 옵션을 사용하여 사용할 백업을 선택할 수 있습니다. 기본적으로 백업 파일은 백업 ID 섹션에 문서화된 대로 생성됩니다.

파일 이름의 <backup-id> 부분을 오버라이드하려면 BACKUP 환경 변수를 설정하세요.

증분 백업을 생성하려면 다음을 실행하세요:

sudo gitlab-backup create INCREMENTAL=yes PREVIOUS_BACKUP=<backup-id>

tar 백업에서 압축 해제된 증분 백업을 생성하려면 SKIP=tar를 사용하세요:

sudo gitlab-backup create INCREMENTAL=yes SKIP=tar

특정 리포지토리 저장소 백업

GitLab 15.0에서 도입됨.

다수의 리포지토리 저장소를 사용할 때,

특정 리포지토리 저장소의 리포지토리를 별도로 백업할 수 있으며 REPOSITORIES_STORAGES 옵션을 사용합니다.

이 옵션은 저장소 이름의 쉼표로 구분된 목록을 허용합니다.

예를 들면:

Linux 패키지 (Omnibus)

sudo gitlab-backup create REPOSITORIES_STORAGES=storage1,storage2

셀프 컴파일

sudo -u git -H bundle exec rake gitlab:backup:create REPOSITORIES_STORAGES=storage1,storage2

특정 레포지토리 백업

GitLab 15.1에서 도입됨.

GitLab 16.1에서 특정 레포지토리 건너뛰기 추가됨.

REPOSITORIES_PATHS 옵션을 사용하여 특정 레포지토리를 백업할 수 있습니다.

유사하게, SKIP_REPOSITORIES_PATHS를 사용하여 특정 레포지토리를 건너뛸 수 있습니다.

두 옵션 모두 프로젝트 또는 그룹 경로의 쉼표로 구분된 목록을 허용합니다. 그룹 경로를 지정하면 그룹 내의 모든 프로젝트와 자식 그룹의 모든 레포지토리가 포함되거나 건너뛰게 됩니다. 사용한 옵션에 따라 다릅니다.

예를 들어, Group A(group-a)의 모든 프로젝트에 대한 모든 레포지토리와 Group B에서 Project C(group-b/project-c)의 레포지토리를 백업하고, Group A의 Project D(group-a/project-d)는 건너뛰려면:

리눅스 패키지 (Omnibus)

  sudo gitlab-backup create REPOSITORIES_PATHS=group-a,group-b/project-c SKIP_REPOSITORIES_PATHS=group-a/project-d

소스 컴파일

  sudo -u git -H bundle exec rake gitlab:backup:create REPOSITORIES_PATHS=group-a,group-b/project-c SKIP_REPOSITORIES_PATHS=group-a/project-d

백업을 원격(클라우드) 스토리지에 업로드

오브젝트 스토리지로 백업을 사용할 때 tar 생성 건너뛰기가 불가능합니다.

백업 스크립트가 생성하는 .tar 파일을 업로드하도록 설정할 수 있습니다 (Fog 라이브러리 사용).

다음 예제에서는 스토리지로 Amazon S3를 사용하지만, Fog는 다른 스토리지 공급 업체도 사용할 수 있게 해줍니다.

GitLab은 또한 AWS, Google 및 Aliyun을 위한 클라우드 드라이버를 가져옵니다.

로컬 드라이버도 사용 가능합니다.

GitLab과 오브젝트 스토리지 사용에 대해 더 알아보기.

Amazon S3 사용하기

리눅스 패키지 (Omnibus)의 경우:

/etc/gitlab/gitlab.rb에 다음을 추가합니다:

gitlab_rails['backup_upload_connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-west-1',
  'aws_access_key_id' => 'AKIAKIAKI',
  'aws_secret_access_key' => 'secret123'
  # IAM 프로파일을 사용하는 경우 aws_access_key_id 및 aws_secret_access_key를 구성하지 마십시오.
  # 'use_iam_profile' => true
}
gitlab_rails['backup_upload_remote_directory'] = 'my.s3.bucket'
# 파일 크기가 100MB에 도달하면 멀티파트 업로드를 사용하는 것이 좋습니다. 바이트로 숫자를 입력하세요.
# gitlab_rails['backup_multipart_chunk_size'] = 104857600

변경 사항을 적용하려면 GitLab을 재구성하세요.

S3 암호화된 버킷

AWS는 서버 측 암호화 모드를 지원합니다:

Amazon S3-관리 키 (SSE-S3)
AWS 키 관리 서비스에 저장된 고객 마스터 키 (CMK) (SSE-KMS)
고객 제공 키 (SSE-C)

원하는 모드를 GitLab과 함께 사용하세요. 각 모드는 유사하지만 약간 다른 구성 방법을 가지고 있습니다.

SSE-S3

SSE-S3를 활성화하려면, 백업 저장 옵션에서 server_side_encryption 필드를 AES256으로 설정합니다. 예를 들어, 리눅스 패키지(Omnibus)에서:

gitlab_rails['backup_upload_storage_options'] = {
  'server_side_encryption' => 'AES256'
}

SSE-KMS

SSE-KMS를 활성화하려면, KMS 키의 Amazon 리소스 이름(ARN)를 arn:aws:kms:region:acct-id:key/key-id 형식으로 필요합니다.

backup_upload_storage_options 구성 설정에서 다음을 설정합니다:

server_side_encryption을 aws:kms로.
server_side_encryption_kms_key_id를 키의 ARN으로.

예를 들어, 리눅스 패키지(Omnibus)에서:

gitlab_rails['backup_upload_storage_options'] = {
  'server_side_encryption' => 'aws:kms',
  'server_side_encryption_kms_key_id' => 'arn:aws:<YOUR KMS KEY ID>:'
}

SSE-C

SSE-C는 다음과 같은 암호화 옵션을 설정해야 합니다:

backup_encryption: AES256.
backup_encryption_key: 인코딩되지 않은 32바이트(256비트) 키. 정확히 32바이트가 아니면 업로드가 실패합니다.

예를 들어, 리눅스 패키지(Omnibus)에서:

gitlab_rails['backup_encryption'] = 'AES256'
gitlab_rails['backup_encryption_key'] = '<YOUR 32-BYTE KEY HERE>'

키에 바이너리 문자가 포함되어 있고 UTF-8로 인코딩할 수 없는 경우, 대신 GITLAB_BACKUP_ENCRYPTION_KEY 환경 변수를 사용하여 키를 지정합니다. 예를 들어:

gitlab_rails['env'] = { 'GITLAB_BACKUP_ENCRYPTION_KEY' => "\xDE\xAD\xBE\xEF" * 8 }

디지털 오션 스페이스

이 예시는 암스테르담(AMS3)의 버킷에 사용할 수 있습니다:

/etc/gitlab/gitlab.rb에 다음을 추가합니다:

gitlab_rails['backup_upload_connection'] = {
  'provider' => 'AWS',
  'region' => 'ams3',
  'aws_access_key_id' => 'AKIAKIAKI',
  'aws_secret_access_key' => 'secret123',
  'endpoint'              => 'https://ams3.digitaloceanspaces.com'
}
gitlab_rails['backup_upload_remote_directory'] = 'my.s3.bucket'

변경 사항을 적용하려면 GitLab 재구성을 수행합니다.

디지털 오션 스페이스를 사용할 때 400 Bad Request 오류 메시지가 표시되면, 그 원인은 백업 암호화를 사용하고 있기 때문일 수 있습니다. 디지털 오션 스페이스는 암호화를 지원하지 않으므로, gitlab_rails['backup_encryption']를 포함한 줄을 제거하거나 주석 처리하세요.

다른 S3 제공업체

모든 S3 제공업체가 Fog 라이브러리와 완전히 호환되는 것은 아닙니다. 예를 들어,

업로드를 시도한 후 411 Length Required 오류 메시지가 표시되는 경우,

기본값에서 aws_signature_version 값을 2로 다운그레이드해야 할 수 있습니다.

이 문제로 인해.

셀프 컴파일 설치의 경우:

home/git/gitlab/config/gitlab.yml를 편집합니다:

  backup:
    # 생략
    upload:
      # Fog 저장소 연결 설정, https://fog.io/storage/ 참조.
      connection:
        provider: AWS
        region: eu-west-1
        aws_access_key_id: AKIAKIAKI
        aws_secret_access_key: 'secret123'
        # IAM 프로필을 사용하는 경우 aws_access_key_id 및 aws_secret_access_key를 비워 두세요.
        # 즉 aws_access_key_id: ''
        # use_iam_profile: 'true'
      # 백업을 저장할 원격 '디렉토리'. S3의 경우, 이는 버킷 이름입니다.
      remote_directory: 'my.s3.bucket'
      # 백업에 사용할 Amazon S3 저장소 클래스 지정, 선택 사항입니다.
      # storage_class: 'STANDARD'
      #
      # AWS 서버 측 암호화를 Amazon 고객 제공 암호 키로 활성화합니다. 선택 사항입니다.
      #   'encryption'은 이 설정이 효과를 가지려면 설정해야 합니다.
      #   'encryption_key'는 Amazon S3에서 암호화 또는 암호 해독에 사용할 256비트 암호 키로 설정해야 합니다.
      #   디스크에 키를 저장하지 않으려면 `GITLAB_BACKUP_ENCRYPTION_KEY`를 통해 키를 지정할 수 있습니다.
      # encryption: 'AES256'
      # encryption_key: '<key>'
      #
      #
      # AWS 서버 측 암호화를 Amazon S3 관리 키로 활성화합니다 (선택 사항)
      # https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html
      # SSE-S3의 경우 'server_side_encryption'을 'AES256'으로 설정합니다.
      # SSE-KMS의 경우 'server_side_encryption'을 'aws:kms'로 설정합니다.
      # 'server_side_encryption_kms_key_id'를 고객 마스터 키의 ARN으로 설정합니다.
      # storage_options:
      #   server_side_encryption: 'aws:kms'
      #   server_side_encryption_kms_key_id: 'arn:aws:kms:YOUR-KEY-ID-HERE'

GitLab을 다시 시작하여 변경 사항을 적용합니다.

S3에 백업을 업로드하는 경우 제한된 액세스 권한을 가진 새 IAM 사용자를 생성해야 합니다. 업로드 사용자에게 백업 업로드만 허용하려면 다음 IAM 프로필을 생성하십시오. my.s3.bucket을 버킷 이름으로 바꾸세요:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "Stmt1412062044000",
      "Effect": "Allow",
      "Action": [
        "s3:AbortMultipartUpload",
        "s3:GetBucketAcl",
        "s3:GetBucketLocation",
        "s3:GetObject",
        "s3:GetObjectAcl",
        "s3:ListBucketMultipartUploads",
        "s3:PutObject",
        "s3:PutObjectAcl"
      ],
      "Resource": [
        "arn:aws:s3:::my.s3.bucket/*"
      ]
    },
    {
      "Sid": "Stmt1412062097000",
      "Effect": "Allow",
      "Action": [
        "s3:GetBucketLocation",
        "s3:ListAllMyBuckets"
      ],
      "Resource": [
        "*"
      ]
    },
    {
      "Sid": "Stmt1412062128000",
      "Effect": "Allow",
      "Action": [
        "s3:ListBucket"
      ],
      "Resource": [
        "arn:aws:s3:::my.s3.bucket"
      ]
    }
  ]
}

Google Cloud Storage 사용하기

백업을 저장하기 위해 Google Cloud Storage를 사용하려면 먼저 Google 콘솔에서 액세스 키를 생성해야 합니다:

Google 스토리지 설정 페이지로 이동합니다.
Interoperability를 선택한 후 액세스 키를 생성합니다.
Access Key와 Secret을 메모하고 다음 구성에서 이를 대체합니다.
버킷의 고급 설정에서 액세스 제어 옵션 Set object-level and bucket-level permissions가 선택되어 있는지 확인합니다.
이미 버킷을 생성했는지 확인합니다.

Linux 패키지(Omnibus)용:

/etc/gitlab/gitlab.rb를 편집합니다:

gitlab_rails['backup_upload_connection'] = {
  'provider' => 'Google',
  'google_storage_access_key_id' => 'Access Key',
  'google_storage_secret_access_key' => 'Secret',

  ## CNAME 버킷(예: foo.example.com)이 있는 경우 백업을 업로드할 때 
  ## SSL 문제에 직면할 수 있습니다("hostname foo.example.com.storage.googleapis.com
  ## 서버 인증서와 일치하지 않음"). 이 경우 다음 설정의 주석을 제거합니다. 
  ## 참고: https://github.com/fog/fog/issues/2834
  #'path_style' => true
}
gitlab_rails['backup_upload_remote_directory'] = 'my.google.bucket'

변경 사항을 적용하기 위해 GitLab 재구성합니다.

소스 컴파일 설치용:

home/git/gitlab/config/gitlab.yml를 편집합니다:

  backup:
    upload:
      connection:
        provider: 'Google'
        google_storage_access_key_id: 'Access Key'
        google_storage_secret_access_key: 'Secret'
      remote_directory: 'my.google.bucket'

변경 사항을 적용하기 위해 GitLab 재시작합니다.

Azure Blob 스토리지 사용하기

Linux 패키지 (Omnibus)

/etc/gitlab/gitlab.rb를 편집합니다:

gitlab_rails['backup_upload_connection'] = {
 'provider' => 'AzureRM',
 'azure_storage_account_name' => '<AZURE STORAGE ACCOUNT NAME>',
 'azure_storage_access_key' => '<AZURE STORAGE ACCESS KEY>',
 'azure_storage_domain' => 'blob.core.windows.net', # 선택 사항
}
gitlab_rails['backup_upload_remote_directory'] = '<AZURE BLOB CONTAINER>'

변경 사항을 적용하기 위해 GitLab 재구성합니다.

소스 컴파일

home/git/gitlab/config/gitlab.yml를 편집합니다:

  backup:
    upload:
      connection:
        provider: 'AzureRM'
        azure_storage_account_name: '<AZURE STORAGE ACCOUNT NAME>'
        azure_storage_access_key: '<AZURE STORAGE ACCESS KEY>'
      remote_directory: '<AZURE BLOB CONTAINER>'

변경 사항을 적용하기 위해 GitLab 재시작합니다.

자세한 내용은 Azure 파라미터 표를 참조하세요.

백업을 위한 사용자 정의 디렉토리 지정하기

이 옵션은 원격 저장소에서만 작동합니다. 백업을 그룹화하려면 DIRECTORY 환경 변수를 전달할 수 있습니다:

sudo gitlab-backup create DIRECTORY=daily
sudo gitlab-backup create DIRECTORY=weekly

원격 스토리지로 백업 업로드 건너뛰기

GitLab을 원격 스토리지에 백업 업로드하도록 구성한 경우

SKIP=remote 옵션을 사용하여 백업을 원격 스토리지로 업로드하는 것을 건너뛸 수 있습니다.

리눅스 패키지 (Omnibus)

sudo gitlab-backup create SKIP=remote

자가 컴파일

sudo -u git -H bundle exec rake gitlab:backup:create SKIP=remote RAILS_ENV=production

로컬로 마운트된 공유에 업로드

Fog Local 스토리지 제공자를 사용하여 로컬로 마운트된 공유(NFS, CIFS, SMB 등)에 백업을 전송할 수 있습니다.

이를 위해 다음 설정 키를 설정해야 합니다:

backup_upload_connection.local_root: 백업이 복사되는 마운트된 디렉터리.
backup_upload_remote_directory: backup_upload_connection.local_root 디렉터리의 하위 디렉터리. 존재하지 않을 경우 생성됩니다.

마운트되면 local_root 키에 설정된 디렉터리는 다음 중 하나의 소유여야 합니다:

git 사용자. 그래서 CIFS 및 SMB에 대해 git 사용자의 uid=로 마운트해야 합니다.
백업 작업을 실행하는 사용자. 리눅스 패키지(Omnibus)에서는 git 사용자입니다.

파일 시스템 성능이 전체 GitLab 성능에 영향을 미칠 수 있으므로,

클라우드 기반 파일 시스템을 스토리지로 사용하는 것을 권장하지 않습니다.

충돌하는 구성 피하기

다음 설정 키를 동일한 경로로 설정하지 마세요:

gitlab_rails['backup_path'] (자가 컴파일 설치의 경우 backup.path).
gitlab_rails['backup_upload_connection'].local_root (자가 컴파일 설치의 경우 backup.upload.connection.local_root).

backup_path 구성 키는 백업 파일의 로컬 위치를 설정합니다. upload 구성 키는 백업 파일이 다른 서버에 업로드될 때 사용하기 위한 것입니다.

이 구성 키가 동일한 위치로 설정되면 업로드 기능이 실패합니다. 왜냐하면 업로드 위치에 이미 백업 파일이 존재하기 때문입니다. 이 실패로 인해 업로드 기능은 백업을 삭제하게 됩니다. 이는 실패한 업로드 시도의 잔여 파일로 간주하기 때문입니다.

로컬로 마운트된 공유에 대한 업로드 구성

리눅스 패키지 (Omnibus)

/etc/gitlab/gitlab.rb 파일을 편집합니다:

gitlab_rails['backup_upload_connection'] = {
  :provider => 'Local',
  :local_root => '/mnt/backups'
}

# 백업을 복사할 마운트된 폴더 내의 디렉터리
# 루트 디렉터리에 저장하려면 '.'을 사용하세요
gitlab_rails['backup_upload_remote_directory'] = 'gitlab_backups'

변경 사항을 적용하기 위해 GitLab을 재구성합니다.

자가 컴파일

home/git/gitlab/config/gitlab.yml 파일을 편집합니다:

backup:
  upload:
    # Fog 스토리지 연결 설정, https://fog.io/storage/ 참조.
    connection:
      provider: Local
      local_root: '/mnt/backups'
    # 백업을 복사할 마운트된 폴더 내의 디렉터리
    # 루트 디렉터리에 저장하려면 '.'을 사용하세요
    remote_directory: 'gitlab_backups'

변경 사항을 적용하기 위해 GitLab을 재시작합니다.

백업 아카이브 권한

GitLab에서 생성된 백업 아카이브(1393513186_2014_02_27_gitlab_backup.tar)는 기본적으로 소유자/그룹이 git/git이고, 권한은 0600입니다. 이는 다른 시스템 사용자가 GitLab 데이터를 읽지 못하도록 하기 위함입니다. 백업 아카이브에 다른 권한이 필요하면 archive_permissions 설정을 사용할 수 있습니다.

Linux 패키지 (Omnibus)

/etc/gitlab/gitlab.rb를 편집합니다:

gitlab_rails['backup_archive_permissions'] = 0644 # 백업 아카이브를 모두가 읽을 수 있도록 만듭니다

GitLab 재구성을 통해 변경 사항을 적용합니다.

Self-compiled

/home/git/gitlab/config/gitlab.yml를 편집합니다:

backup:
  archive_permissions: 0644 # 백업 아카이브를 모두가 읽을 수 있도록 만듭니다

GitLab 재시작을 통해 변경 사항을 적용합니다.

크론을 구성하여 매일 백업 생성

경고: 다음 크론 작업은 GitLab 구성 파일이나 SSH 호스트 키를 백업하지 않습니다.

저장소와 GitLab 메타데이터를 백업하는 크론 작업을 예약할 수 있습니다.

Linux 패키지 (Omnibus)

root 사용자의 크론탭을 편집합니다:
```
sudo su -
crontab -e
```
다음 줄을 추가하여 매일 오전 2시에 백업을 예약합니다:
```
0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1
```

Self-compiled

git 사용자의 크론탭을 편집합니다:
```
sudo -u git crontab -e
```

다음 줄을 하단에 추가합니다:

# 매일 오전 2시에 GitLab 저장소와 SQL 데이터베이스의 전체 백업 생성
0 2 * * * cd /home/git/gitlab && PATH=/usr/local/bin:/usr/bin:/bin bundle exec rake gitlab:backup:create RAILS_ENV=production CRON=1

CRON=1 환경 설정은 모든 진행 상황 출력을 숨기도록 백업 스크립트를 지시합니다. 이는 크론 스팸을 줄이기 위해 권장됩니다. 그러나 백업 문제를 해결할 때는 CRON=1을 --trace로 교체하여 자세히 기록할 수 있습니다.

로컬 파일의 백업 생명을 제한하기 (이전 백업 정리)

경고: 이 섹션에서 설명하는 프로세스는 백업에 사용자 지정 파일 이름을 사용한 경우 작동하지 않습니다.

정기적인 백업이 모든 디스크 공간을 사용하는 것을 방지하기 위해 백업의 제한된 수명을 설정할 수 있습니다. 다음 번 백업 작업이 실행될 때 backup_keep_time보다 오래된 백업이 정리됩니다.

이 구성 옵션은 로컬 파일만 관리합니다. GitLab은 사용자가 파일을 나열하고 삭제할 수 있는 권한이 없기 때문에 서드파티 객체 저장소에 저장된 오래된 파일을 정리하지 않습니다. 객체 저장소에 대한 적절한 보존 정책을 구성하는 것이 좋습니다 (예: AWS S3).

Linux 패키지 (Omnibus)

/etc/gitlab/gitlab.rb를 편집합니다:

## 백업 생명을 7일로 제한 - 604800초
gitlab_rails['backup_keep_time'] = 604800

GitLab 재구성을 통해 변경 사항을 적용합니다.

Self-compiled

/home/git/gitlab/config/gitlab.yml를 편집합니다:

backup:
  ## 백업 생명을 7일로 제한 - 604800초
  keep_time: 604800

GitLab 재시작을 통해 변경 사항을 적용합니다.

PgBouncer를 사용하는 설치의 백업 및 복원

PgBouncer 연결을 통해 GitLab을 백업하거나 복원하지 마십시오. 이러한 작업은 PgBouncer를 우회하고 PostgreSQL 기본 데이터베이스 노드에 직접 연결해야 하며, 그렇지 않으면 GitLab 서비스 중단이 발생할 수 있습니다.

PgBouncer와 함께 GitLab 백업 또는 복원 작업을 사용할 때, 다음과 같은 오류 메시지가 표시됩니다:

ActiveRecord::StatementInvalid: PG::UndefinedTable

GitLab 백업이 실행될 때마다, GitLab은 500 오류를 발생시키고 누락된 테이블에 대한 오류가 PostgreSQL에 의해 기록됩니다:

ERROR: relation "tablename" does not exist at character 123

이는 작업이 pg_dump를 사용하기 때문에 발생하며, 이는 CVE-2018-1058에 대한 대응으로 null 검색 경로를 설정하고 모든 SQL 쿼리에 스키마를 명시적으로 포함합니다.

PgBouncer에서 연결이 트랜잭션 풀링 모드로 재사용되기 때문에, PostgreSQL은 기본 public 스키마를 검색하지 못합니다. 결과적으로, 검색 경로의 삭제로 인해 테이블과 열이 누락된 것으로 나타납니다.

PgBouncer 우회

이를 해결하는 방법은 두 가지가 있습니다:

백업 작업을 위한 데이터베이스 설정을 환경 변수를 사용하여 재정의합니다.
노드를 재구성하여 PostgreSQL 기본 데이터베이스 노드에 직접 연결합니다.

환경 변수 재정의

여러 데이터베이스 지원은 GitLab 16.5에 도입되었습니다.

기본적으로 GitLab은 구성 파일(database.yml)에 저장된 데이터베이스 구성을 사용합니다. 그러나 GITLAB_BACKUP_로 접두사가 붙은 환경 변수를 설정하여 백업 및 복원 작업을 위한 데이터베이스 설정을 재정의할 수 있습니다:

GITLAB_BACKUP_PGHOST
GITLAB_BACKUP_PGUSER
GITLAB_BACKUP_PGPORT
GITLAB_BACKUP_PGPASSWORD
GITLAB_BACKUP_PGSSLMODE
GITLAB_BACKUP_PGSSLKEY
GITLAB_BACKUP_PGSSLCERT
GITLAB_BACKUP_PGSSLROOTCERT
GITLAB_BACKUP_PGSSLCRL
GITLAB_BACKUP_PGSSLCOMPRESSION

예를 들어, 데이터베이스 호스트를 192.168.1.10으로, 포트를 5432로 재정의하려면 Linux 패키지(Omnibus)에서 다음과 같이 실행합니다:

sudo GITLAB_BACKUP_PGHOST=192.168.1.10 GITLAB_BACKUP_PGPORT=5432 /opt/gitlab/bin/gitlab-backup create

여러 데이터베이스에서 GitLab을 실행하는 경우, 데이터베이스 이름을 환경 변수에 포함하여 데이터베이스 설정을 재정의할 수 있습니다. 예를 들어 main 및 ci 데이터베이스가 서로 다른 데이터베이스 서버에 호스팅되는 경우, GITLAB_BACKUP_ 접두사 뒤에 이름을 추가하고 PG* 이름은 그대로 두면 됩니다:

sudo GITLAB_BACKUP_MAIN_PGHOST=192.168.1.10 GITLAB_BACKUP_CI_PGHOST=192.168.1.12 /opt/gitlab/bin/gitlab-backup create

이러한 매개변수가 하는 일에 대한 자세한 내용은 PostgreSQL 문서를 참조하십시오.

`gitaly-backup`를 이용한 리포지토리 백업 및 복원

gitaly-backup 바이너리는 백업 Rake 작업에 의해 사용되며 Gitaly에서 리포지토리 백업을 생성하고 복원하는 데 사용됩니다.

gitaly-backup은 GitLab에서 Gitaly로 직접 RPC를 호출하는 이전 백업 방법을 대체합니다.

백업 Rake 작업은 이 실행 파일을 찾을 수 있어야 합니다. 대부분의 경우, 바이너리의 경로를 변경할 필요가 없으며 기본 경로인 /opt/gitlab/embedded/bin/gitaly-backup로 잘 작동해야 합니다.

경로를 변경해야 하는 특정 이유가 있는 경우, Linux 패키지(Omnibus)에서 구성할 수 있습니다:

/etc/gitlab/gitlab.rb에 다음을 추가합니다:

gitlab_rails['backup_gitaly_backup_path'] = '/path/to/gitaly-backup'

GitLab 재구성하기로 변경 사항이 적용되도록 합니다.

대체 백업 전략

모든 배포는 서로 다른 기능을 가질 수 있으므로, 먼저 백업해야 할 데이터를 검토하여 이러한 기능을 활용할 수 있는지, 그리고 어떻게 활용할 수 있는지 더 잘 이해해야 합니다.

예를 들어, Amazon RDS를 사용하는 경우, GitLab PostgreSQL 데이터를 처리하기 위해 내장된 백업 및 복원 기능을 사용하고, 백업 명령 사용 시 PostgreSQL 데이터를 제외하는 것을 선택할 수 있습니다.

다음과 같은 경우에는 파일 시스템 데이터 전송 또는 스냅샷을 백업 전략의 일부로 사용하는 것을 고려하십시오:

GitLab 인스턴스에 많은 Git 리포지토리 데이터가 있고 GitLab 백업 스크립트가 너무 느린 경우.
GitLab 인스턴스에 많은 포크된 프로젝트가 있으며 정기적인 백업 작업이 모두에 대해 Git 데이터를 중복적으로 생성하는 경우.
GitLab 인스턴스에 문제가 있으며 정기적인 백업 및 가져오기 Rake 작업을 사용할 수 없는 경우.

Gitaly 클러스터는 스냅샷 백업을 지원하지 않습니다.

파일 시스템 데이터 전송 또는 스냅샷을 사용할 것을 고려할 때:

이러한 방법을 사용하여 한 운영 체제에서 다른 운영 체제로 이전하는 것을 피하십시오. 소스와 대상의 운영 체제는 가능한 한 유사해야 합니다. 예를 들어, Ubuntu에서 RHEL로 이전하기 위해 이러한 방법을 사용하지 마십시오.
데이터 일관성은 매우 중요합니다. 파일 시스템 전송(예: rsync)을 수행하기 전에 GitLab (sudo gitlab-ctl stop)을 중지해야 합니다.

예제: Amazon Elastic Block Store (EBS)

Amazon AWS에서 호스팅되는 Linux 패키지(Omnibus)를 사용하는 GitLab 서버.
ext4 파일 시스템이 포함된 EBS 드라이브가 /var/opt/gitlab에 마운트되어 있습니다.
이 경우 EBS 스냅샷을 통해 애플리케이션 백업을 생성할 수 있습니다.
백업에는 모든 리포지토리, 업로드 및 PostgreSQL 데이터가 포함됩니다.

예제: 논리 볼륨 관리자(LVM) 스냅샷 + rsync

/var/opt/gitlab에 마운트된 LVM 논리 볼륨을 사용하는 Linux 패키지(Omnibus)의 GitLab 서버.
rsync를 사용하여 /var/opt/gitlab 디렉토리를 복제하는 것은 rsync가 실행되는 동안 너무 많은 파일이 변경되므로 신뢰할 수 없습니다.
/var/opt/gitlab를 rsync하는 대신, 임시 LVM 스냅샷을 생성하고 이를 /mnt/gitlab_backup에 읽기 전용 파일 시스템으로 마운트합니다.
이제 원격 서버에 일관된 복제본을 생성하는 더 긴 rsync 작업을 수행할 수 있습니다.
복제본에는 모든 리포지토리, 업로드 및 PostgreSQL 데이터가 포함됩니다.

가상화된 서버에서 GitLab을 실행하는 경우 전체 GitLab 서버의 VM 스냅샷을 생성할 수도 있습니다. 그러나 VM 스냅샷을 생성하려면 서버를 종료해야 할 수 있어 이 솔루션의 실제 사용에 제한이 있을 수 있습니다.

저장소 데이터를 별도로 백업하기

먼저, 저장소 제외에 따라 기존 GitLab 데이터를 백업하는 것을 확실히 하세요:

Linux 패키지 (Omnibus)

sudo gitlab-backup create SKIP=repositories

직접 컴파일

sudo -u git -H bundle exec rake gitlab:backup:create SKIP=repositories RAILS_ENV=production

디스크에 Git 저장소 데이터를 수동으로 백업하는 여러 가지 가능한 전략이 있습니다:

이전 Amazon EBS 드라이브 스냅샷 또는 LVM 스냅샷 + rsync의 예와 같은 스냅샷을 사용하세요.
GitLab Geo를 사용하고 Geo 보조 사이트의 저장소 데이터에 의존하세요.
쓰기 방지 및 Git 저장소 데이터 복사.
저장소를 읽기 전용으로 표시하여 온라인 백업 생성하기 (실험적).

쓰기 방지 및 Git 저장소 데이터 복사

Git 저장소는 일관된 방식으로 복사해야 합니다. 동시에 쓰기 작업이 진행되는 동안 복사해서는 안 되며, 이는 불일치나 손상 문제를 유발할 수 있습니다. 더 자세한 내용은 이슈 #270422에서 더 긴 논의가 있습니다.

Git 저장소 데이터에 대한 쓰기를 방지하는 방법으로 두 가지 접근 방법이 있습니다:

유지 관리 모드를 사용하여 GitLab을 읽기 전용 상태로 설정하세요.
저장소를 백업하기 전에 모든 Gitaly 서비스를 중지하여 명시적으로 다운타임을 생성하세요:
```
sudo gitlab-ctl stop gitaly
# git 데이터 복사 단계 실행
sudo gitlab-ctl start gitaly
```

데이터 불일치 및 손상 문제를 방지하기 위해 복사되는 데이터에 대한 쓰기를 방지하는 한, 어떤 방법을 사용하여도 Git 저장소 데이터를 복사할 수 있습니다. 선호도와 안전성에 따라 권장되는 방법은 다음과 같습니다:

아카이브 모드, 삭제 및 체크섬 옵션을 사용하여 rsync를 사용하세요, 예를 들어:

rsync -aR --delete --checksum source destination # 순서를 안전하게 유지하세요, 뒤집히면 기존 데이터가 삭제됩니다

tar 파이프를 사용하여 전체 저장소 디렉터리를 다른 서버 또는 위치로 복사합니다.
sftp, scp, cp 또는 기타 복사 방법을 사용하세요.

저장소를 읽기 전용으로 마킹하여 온라인 백업 생성하기 (실험적)

인스턴스 전반에 걸쳐 다운타임이 필요하지 않게 저장소를 백업하는 한 가지 방법은 기본 데이터를 복사하는 동안 프로젝트를 프로그램matically으로 읽기 전용으로 표시하는 것입니다.

이 방법에는 몇 가지 가능한 단점이 있습니다:

저장소 크기에 비례하여 일정 기간 동안 저장소가 읽기 전용입니다.
각 프로젝트를 읽기 전용으로 표시해야 하므로 백업 완료에 더 오랜 시간이 걸립니다, 이로 인해 불일치가 발생할 수 있습니다. 예를 들어, 백업이 진행되는 첫 번째 프로젝트에 대한 마지막 데이터와 가장 최근에 백업되는 프로젝트 간의 날짜 불일치가 발생할 수 있습니다.
포크 네트워크는 내부의 프로젝트가 백업되는 동안 전체적으로 읽기 전용이어야 하며, 이는 풀 저장소에 대한 잠재적인 변경을 방지합니다.

이 프로세스를 자동화하려는 실험적 스크립트가 있습니다 Geo 팀 Runbooks 프로젝트에서 확인할 수 있습니다.

GitLab 백업

간단한 백업 절차

백업 확장

어떤 데이터를 백업해야 하나요?

PostgreSQL 데이터베이스

Git 저장소

Blob

오브젝트 스토리지

컨테이너 레지스트리

구성 파일 저장

기타 데이터

커맨드 라인 인터페이스

요구 사항

백업 명령어

백업 옵션

백업 전략 옵션

백업 파일 이름

백업 압축

기본 압축: 가장 빠른 방법으로 Gzip

가장 느린 방법으로 Gzip

압축 없음

pigz를 사용한 병렬 압축

zstd를 사용한 병렬 압축

전송 가능한 아카이브 확인

백업에서 특정 데이터 제외

tar 생성 건너뛰기

서버 측 저장소 백업 생성

Git 리포지토리 동시 백업

증분 리포지토리 백업

특정 리포지토리 저장소 백업

특정 레포지토리 백업

백업을 원격(클라우드) 스토리지에 업로드

Amazon S3 사용하기

S3 암호화된 버킷

SSE-S3

SSE-KMS

SSE-C

디지털 오션 스페이스

다른 S3 제공업체

Google Cloud Storage 사용하기

Azure Blob 스토리지 사용하기

백업을 위한 사용자 정의 디렉토리 지정하기

원격 스토리지로 백업 업로드 건너뛰기

로컬로 마운트된 공유에 업로드

충돌하는 구성 피하기

로컬로 마운트된 공유에 대한 업로드 구성

백업 아카이브 권한

크론을 구성하여 매일 백업 생성

로컬 파일의 백업 생명을 제한하기 (이전 백업 정리)

PgBouncer를 사용하는 설치의 백업 및 복원

PgBouncer 우회

환경 변수 재정의

gitaly-backup를 이용한 리포지토리 백업 및 복원

대체 백업 전략

저장소 데이터를 별도로 백업하기

쓰기 방지 및 Git 저장소 데이터 복사

저장소를 읽기 전용으로 마킹하여 온라인 백업 생성하기 (실험적)

도움말

기능 사용 가능성과 제품 평가판

도움받기

`pigz`를 사용한 병렬 압축

`zstd`를 사용한 병렬 압축

`gitaly-backup`를 이용한 리포지토리 백업 및 복원