GitLab 백업은 데이터를 보호하고 재해 복구에 도움을 줍니다.

최적의 백업 전략은 GitLab 배포 구성, 데이터 볼륨, 스토리지 위치에 따라 달라집니다. 이러한 요소들이 사용할 백업 방법, 백업 저장 위치, 백업 일정 구성 방법을 결정합니다.

대규모 GitLab 인스턴스의 경우, 다음과 같은 대안적 백업 전략을 사용할 수 있습니다:

• 증분 백업.

• 특정 리포지터리의 백업.

• 여러 스토리지 위치에 걸친 백업.

백업에 포함되는 데이터#

• 외부 머지 리퀘스트 diff가 GitLab 17.1에서 도입됨.

GitLab은 전체 인스턴스를 백업하기 위한 명령줄 인터페이스를 제공합니다. 기본적으로 백업은 단일 압축 tar 파일 형태의 아카이브를 생성합니다. 이 파일에는 다음이 포함됩니다:

• 데이터베이스 데이터 및 구성

• 계정 및 그룹 설정

• CI/CD 아티팩트 및 job 로그

• Git 리포지터리 및 LFS 객체

• 외부 머지 리퀘스트 diff

• 패키지 레지스트리 데이터 및 컨테이너 레지스트리 이미지

• 프로젝트 및 그룹 위키

• 프로젝트 수준 첨부 파일 및 업로드

• Secure Files

• GitLab Pages 콘텐츠

• Terraform 상태

• 스니펫

백업에 포함되지 않는 데이터#

구성 파일 저장하기를 읽고 해당 파일들을 별도로 백업하는 것을 강력히 권장합니다.

• Redis (및 Sidekiq job)

• Linux 패키지(Omnibus) / Docker / 직접 컴파일 설치의 오브젝트 스토리지

• 글로벌 서버 훅

• 파일 훅

• GitLab 구성 파일 (/etc/gitlab)

• TLS 및 SSH 관련 키와 인증서

• 기타 시스템 파일

간단한 백업 절차#

대략적인 지침으로, 100 GB 미만의 데이터를 가진 1k 레퍼런스 아키텍처를 사용하는 경우 다음 단계를 따르세요:

• 백업 명령을 실행하세요.

• 해당하는 경우 오브젝트 스토리지를 백업하세요.

• 시스템 구성 파일을 수동으로 백업하세요.

참고 링크:

• 1k 레퍼런스 아키텍처

• 백업 명령 세부 정보

• 오브젝트 스토리지 구성

• 구성 파일 가이드

백업 확장#

GitLab 데이터의 양이 증가할수록 백업 명령 실행 시간이 길어집니다. Git 리포지터리를 동시에 백업하거나 증분 리포지터리 백업을 사용하는 등의 백업 옵션으로 실행 시간을 줄일 수 있습니다. 어느 시점이 되면 백업 명령 자체만으로는 실용적이지 않게 됩니다. 예를 들어 24시간 이상이 소요될 수 있습니다.

GitLab 18.0부터 많은 수의 참조(브랜치, 태그)가 있는 리포지터리의 리포지터리 백업 성능이 크게 향상되었습니다. 이 개선으로 인해 영향을 받는 리포지터리의 백업 시간이 수 시간에서 수 분으로 단축될 수 있습니다. 이 향상의 혜택을 받기 위해 구성 변경이 필요하지 않습니다.

경우에 따라 백업 확장을 위해 아키텍처 변경이 필요할 수 있습니다.

더 읽어보기:

• 증분 리포지터리 백업.

• Git 리포지터리 동시 백업.

• 대규모 레퍼런스 아키텍처 백업 및 복원.

• 대안적 백업 전략.

• GitLab 리포지터리 백업 시간 단축에 관한 블로그 게시물.

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

다음 데이터를 백업해야 합니다.

PostgreSQL 데이터베이스#

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

일반적으로, 이 데이터는 이슈 및 머지 리퀘스트 콘텐츠, 댓글, 권한, 자격 증명과 같은 웹 인터페이스의 대부분의 사용자 생성 콘텐츠에 대한 단일 진실 공급원(Single Source Of Truth, SSOT)입니다.

PostgreSQL은 또한 HTML로 렌더링된 Markdown과 같은 캐시된 데이터와 기본적으로 머지 리퀘스트 diff를 보유합니다. 그러나 머지 리퀘스트 diff는 파일 시스템이나 오브젝트 스토리지로 오프로드하도록 구성할 수도 있습니다.

Gitaly Cluster(Praefect)는 Gitaly 노드를 관리하기 위한 SSOT로 PostgreSQL 데이터베이스를 사용합니다.

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

안타깝게도, 데이터베이스가 클수록 pg_dump 실행 시간이 길어집니다. 상황에 따라 어느 시점에서 지속 시간이 실용적이지 않게 됩니다(예: 수 일). 데이터베이스가 100 GB를 초과하면 pg_dump 및 백업 명령을 사용하기 어려울 수 있습니다. 자세한 내용은 대안적 백업 전략을 참조하세요.

Git 리포지터리#

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

• 단일 디스크.

• 단일 마운트 포인트로 마운트된 여러 디스크(예: RAID 배열).

• LVM 사용.

각 프로젝트는 최대 3개의 서로 다른 리포지터리를 가질 수 있습니다:

• 소스 코드가 저장되는 프로젝트 리포지터리.

• 위키 콘텐츠가 저장되는 위키 리포지터리.

• 디자인 아티팩트가 인덱싱되는 디자인 리포지터리(에셋은 실제로 LFS에 있음).

이들 모두는 동일한 샤드에 위치하며, 위키와 디자인 리포지터리의 경우 -wiki 및 -design 접미사가 붙은 동일한 기본 이름을 공유합니다.

개인 및 프로젝트 스니펫, 그룹 위키 콘텐츠는 Git 리포지터리에 저장됩니다.

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

백업 명령은 각 리포지터리에 대해 Git 번들을 생성하고 모두 묶습니다. 이는 풀 리포지터리 데이터를 모든 포크에 복제합니다. 테스트에서 100 GB의 Git 리포지터리를 백업하고 S3에 업로드하는 데 약 2시간 이상이 걸렸습니다. 약 400 GB의 Git 데이터에서 백업 명령은 정기 백업에 적합하지 않을 수 있습니다. 자세한 내용은 대안적 백업 전략을 참조하세요.

블롭#

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

• 특정 위치의 파일 시스템.

• 오브젝트 스토리지 솔루션. 오브젝트 스토리지 솔루션은 다음이 될 수 있습니다:

Amazon S3 및 Google Cloud Storage와 같은 클라우드 기반.

• 자체 호스팅 S3 호환 오브젝트 스토리지.

• 오브젝트 스토리지 호환 API를 노출하는 스토리지 어플라이언스.

오브젝트 스토리지#

백업 명령은 파일 시스템에 저장되지 않은 블롭을 백업하지 않습니다. 오브젝트 스토리지를 사용하는 경우, 오브젝트 스토리지 제공업체에서 백업을 활성화해야 합니다.

제공업체별 백업 가이드:

• Amazon S3 백업

• Google Cloud Storage Transfer Service

• Google Cloud Storage Object Versioning

참고 링크:

• 백업 명령 세부 정보

• 오브젝트 스토리지 구성

컨테이너 레지스트리#

GitLab 컨테이너 레지스트리 스토리지는 다음 중 하나로 구성할 수 있습니다:

• 특정 위치의 파일 시스템.

• 오브젝트 스토리지 솔루션. 오브젝트 스토리지 솔루션은 다음이 될 수 있습니다:

Amazon S3 및 Google Cloud Storage와 같은 클라우드 기반.

• 자체 호스팅 S3 호환 오브젝트 스토리지.

• 오브젝트 스토리지 호환 API를 노출하는 스토리지 어플라이언스.

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

메타데이터 데이터베이스#

컨테이너 레지스트리 메타데이터 데이터베이스를 활성화한 경우, 백업 중에 레지스트리 데이터베이스에 대한 액세스를 구성해야 합니다. 필요한 자격 증명을 구성하려면 GitLab 설치 유형에 맞는 지침을 따르세요:

• Linux 패키지 지침

• GitLab Helm 차트

참고 링크:

• GitLab 컨테이너 레지스트리

• 오브젝트 스토리지 구성

구성 파일 저장하기#

GitLab이 제공하는 백업 Rake 태스크는 구성 파일을 저장하지 않습니다. 이에 대한 주요 이유는 데이터베이스에 2단계 인증 및 CI/CD 보안 변수에 대한 암호화된 정보가 포함된 항목들이 있기 때문입니다. 암호화된 정보를 키와 같은 위치에 저장하면 암호화를 사용하는 목적이 무의미해집니다. 예를 들어, 시크릿 파일에는 데이터베이스 암호화 키가 포함되어 있습니다. 이것을 잃으면, GitLab 애플리케이션은 데이터베이스의 암호화된 값을 복호화할 수 없게 됩니다.

또한, 업그레이드 후 시크릿 파일이 변경될 수 있습니다.

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

또한 TLS 키와 인증서(/etc/gitlab/ssl, /etc/gitlab/trusted-certs) 및 SSH 호스트 키도 백업하는 것이 좋습니다. 전체 머신 복원을 수행해야 하는 경우 중간자 공격(man-in-the-middle attack) 경고를 방지할 수 있습니다.

드물게 시크릿 파일을 분실한 경우, 시크릿 파일 분실 시를 참조하세요.

기타 데이터#

GitLab은 Redis를 캐시 저장소로 사용하면서 백그라운드 job 시스템인 Sidekiq를 위한 영구 데이터를 보관하는 데도 사용합니다. 제공된 백업 명령은 Redis 데이터를 백업하지 않습니다. 이는 백업 명령으로 일관성 있는 백업을 수행하려면 대기 중이거나 실행 중인 백그라운드 job이 없어야 함을 의미합니다.

Elasticsearch는 고급 검색을 위한 선택적 데이터베이스입니다. 소스 코드 수준과 이슈, 머지 리퀘스트, 토론에서의 사용자 생성 콘텐츠 모두에서 검색을 개선할 수 있습니다. 백업 명령은 Elasticsearch 데이터를 백업하지 않습니다. Elasticsearch 데이터는 복원 후 PostgreSQL 데이터에서 재생성할 수 있습니다.

수동 백업 옵션:

• Redis 백업 절차

• Elasticsearch 백업 절차

참고 링크: 백업 명령 세부 정보.

요구 사항#

백업 및 복원을 수행하려면 시스템에 Rsync가 설치되어 있는지 확인하세요. GitLab을 설치한 방법에 따라:

• Linux 패키지를 사용한 경우, Rsync가 이미 설치되어 있습니다.

• 직접 컴파일을 사용한 경우, rsync가 설치되어 있는지 확인하고 없으면 설치하세요.

백업 명령#

• 백업 명령은 Linux 패키지(Omnibus) / Docker / 직접 컴파일 설치에서 오브젝트 스토리지의 항목을 백업하지 않습니다.

• 백업 명령은 PgBouncer를 사용하는 경우, 성능 이유 또는 Patroni 클러스터와 함께 사용할 때 추가 파라미터가 필요합니다.

• GitLab이 생성된 것과 정확히 동일한 버전 및 유형(CE/EE)의 GitLab에만 백업을 복원할 수 있습니다.

중요한 고려 사항:

• 오브젝트 스토리지 제한 사항

• PgBouncer 구성 요구 사항

백업을 생성하려면:

sudo gitlab-backup create

docker exec -t <container name> gitlab-backup create

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

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

• 영구적이며 자동 확장의 대상이 아닐 것.

• GitLab Rails 애플리케이션이 이미 설치되어 있을 것. Puma 또는 Sidekiq가 실행 중이면 Rails가 설치된 것입니다.

• 백업 파일을 생성할 충분한 스토리지와 메모리를 보유할 것.

예제 출력:

Dumping database tables:
- Dumping table events... [DONE]
- Dumping table issues... [DONE]
- Dumping table keys... [DONE]
- Dumping table merge_requests... [DONE]
- Dumping table milestones... [DONE]
- Dumping table namespaces... [DONE]
- Dumping table notes... [DONE]
- Dumping table projects... [DONE]
- Dumping table protected_branches... [DONE]
- Dumping table schema_migrations... [DONE]
- Dumping table services... [DONE]
- Dumping table snippets... [DONE]
- Dumping table taggings... [DONE]
- Dumping table tags... [DONE]
- Dumping table users... [DONE]
- Dumping table users_projects... [DONE]
- Dumping table web_hooks... [DONE]
- Dumping table wikis... [DONE]
Dumping repositories:
- Dumping repository abcd... [DONE]
Creating backup archive: <backup-id>_gitlab_backup.tar [DONE]
Deleting tmp directories...[DONE]
Deleting old backups... [SKIPPING]

백업 프로세스에 대한 자세한 내용은 백업 아카이브 프로세스를 참조하세요.

백업 옵션#

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

백업 전략 옵션#

기본 백업 전략은 Linux 명령 tar와 gzip을 사용하여 각 데이터 위치에서 백업으로 데이터를 스트리밍하는 방식입니다. 이 방식은 대부분의 경우 잘 작동하지만 데이터가 빠르게 변경되는 경우 문제가 발생할 수 있습니다.

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

부작용으로는 백업 프로세스가 최대 1배의 추가 디스크 공간을 사용한다는 것입니다. 프로세스는 각 단계에서 임시 파일을 최대한 정리하여 문제가 복잡해지지 않도록 하지만, 대규모 설치의 경우 상당한 변화가 될 수 있습니다.

기본 스트리밍 전략 대신 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 데이터베이스 덤프.

• 블롭(예: 업로드, job 아티팩트, 외부 머지 리퀘스트 diff).

참고 링크:

• 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를 사용한 병렬 압축#

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

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

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

pigz는 gzip 형식으로 압축하므로 pigz로 압축된 백업을 압축 해제하는 데 반드시 pigz를 사용할 필요는 없습니다. 그러나 gzip에 비해 성능 이점이 있을 수 있습니다. pigz로 백업을 압축 해제하는 예:

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

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

zstd를 사용한 병렬 압축#

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

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

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

zstd로 백업을 압축 해제하는 예:

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

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

아카이브가 전송 가능한지 확인#

rsync로 생성된 아카이브를 전송할 수 있는지 확인하려면 GZIP_RSYNCABLE=yes 옵션을 설정하세요. 이 옵션은 gzip의 --rsyncable 옵션을 설정하며, 백업 파일명 옵션 설정과 함께 사용할 때만 유용합니다.

gzip의 --rsyncable 옵션은 모든 배포판에서 사용 가능하지 않을 수 있습니다. 사용 가능한지 확인하려면 gzip --help를 실행하거나 man 페이지를 참조하세요.

sudo gitlab-backup create BACKUP=dump GZIP_RSYNCABLE=yes

백업에서 특정 데이터 제외#

설치 유형에 따라 백업 생성 시 건너뛸 수 있는 구성 요소가 약간 다릅니다.

sudo gitlab-backup create SKIP=db,uploads

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 파일이 생성되지 않습니다.)

SKIP 변수에 tar를 추가하면 중간 파일에 사용되는 디렉터리에 백업이 포함된 파일과 디렉터리가 남아 있습니다. 이 파일들은 새 백업이 생성되면 덮어쓰이므로, 시스템에 하나의 백업만 보관할 수 있어 다른 곳에 복사해야 합니다.

sudo gitlab-backup create SKIP=tar

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

서버 측 리포지터리 백업 생성#

• 최신 백업 대신 지정된 백업을 복원하는 gitlab-backup의 서버 측 지원이 GitLab 16.6에 도입됨.

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

• backup-utility에서의 서버 측 지원이 GitLab 17.0에 도입됨.

큰 리포지터리 백업을 백업 아카이브에 저장하는 대신, 각 리포지터리를 호스팅하는 Gitaly 노드가 백업 생성 및 오브젝트 스토리지로의 스트리밍을 담당하도록 리포지터리 백업을 구성할 수 있습니다. 이를 통해 백업 생성 및 복원에 필요한 네트워크 리소스를 줄일 수 있습니다.

• Gitaly에서 서버 측 백업 대상 구성.

• 리포지터리 서버 측 옵션을 사용하여 백업을 생성하세요. 다음 예시를 참조하세요.

sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true

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

kubectl exec  -it -- backup-utility --repositories-server-side

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

Git 리포지터리 동시 백업#

여러 리포지터리 스토리지를 사용하는 경우, CPU 시간을 최대한 활용하기 위해 리포지터리를 동시에 백업하거나 복원할 수 있습니다. Rake 태스크의 기본 동작을 수정하는 데 다음 변수들을 사용할 수 있습니다:

• GITLAB_BACKUP_MAX_CONCURRENCY: 동시에 백업할 최대 프로젝트 수. 기본값은 논리 CPU 수입니다.

• GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY: 각 스토리지에서 동시에 백업할 최대 프로젝트 수. 이를 통해 리포지터리 백업을 여러 스토리지에 분산할 수 있습니다. 기본값은 2입니다.

예를 들어, 4개의 리포지터리 스토리지가 있는 경우:

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

toolbox:
#...
    extra: {}
    extraEnv:
      GITLAB_BACKUP_MAX_CONCURRENCY: 4
      GITLAB_BACKUP_MAX_STORAGE_CONCURRENCY: 1

증분 리포지터리 백업#

리포지터리만 증분 백업을 지원합니다. 따라서 INCREMENTAL=yes를 사용하면 태스크가 독립적인 백업 tar 아카이브를 생성합니다. 이는 리포지터리를 제외한 모든 하위 태스크가 여전히 전체 백업을 생성하기 때문입니다(기존 전체 백업을 덮어씁니다). 모든 하위 태스크에 대한 증분 백업 지원을 위한 기능 요청은 이슈 19256을 참조하세요.

증분 리포지터리 백업은 마지막 백업 이후의 변경 사항만 각 리포지터리의 백업 번들에 포함하기 때문에 전체 리포지터리 백업보다 빠를 수 있습니다. gitlab-backup으로 생성된 백업 아카이브는 원본 전체 백업에서 각 리포지터리를 복원하는 데 필요한 모든 단계를 포함하므로 이식 가능하고 독립적입니다.

새 GitLab 인스턴스(기존 데이터 없음)에 증분 백업을 복원하려면 전체 백업에서 증분 백업을 생성해야 합니다. 기본 백업을 생성할 때 백업 구성 요소를 건너뛰지 마세요.

서버 측 리포지터리 백업을 사용하면 증분 리포지터리 백업 파일이 오브젝트 스토리지에 별도로 저장됩니다. 각 증분은 원본 전체 백업으로 거슬러 올라가는 모든 이전 단계에 의존합니다.

오브젝트 스토리지에서 증분 백업 파일을 삭제하지 마세요. 중간 파일이 삭제되면(예: 오브젝트 스토리지 수명 주기 정책을 통해) 백업 체인이 끊어져 백업을 복원할 수 없습니다.

자세한 내용은 증분 리포지터리 백업 복원을 참조하세요.

사용할 백업을 선택하려면 PREVIOUS_BACKUP=<backup-id> 옵션을 사용하세요. 기본적으로 백업 파일은 백업 ID 섹션에 설명된 대로 생성됩니다. BACKUP 환경 변수를 설정하여 파일명의 <backup-id> 부분을 재정의할 수 있습니다.

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

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

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

sudo gitlab-backup create INCREMENTAL=yes SKIP=tar

특정 리포지터리 스토리지 백업#

여러 리포지터리 스토리지를 사용하는 경우, REPOSITORIES_STORAGES 옵션을 사용하여 특정 리포지터리 스토리지의 리포지터리를 별도로 백업할 수 있습니다. 이 옵션은 쉼표로 구분된 스토리지 이름 목록을 허용합니다.

예를 들면:

sudo gitlab-backup create REPOSITORIES_STORAGES=storage1,storage2

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

특정 리포지터리 백업#

• 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)는 건너뛰려면:

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

REPOSITORIES_PATHS=group-a SKIP_REPOSITORIES_PATHS=group-a/project_a2 backup-utility --skip db,registry,uploads,artifacts,lfs,packages,external_diffs,terraform_state,ci_secure_files,agent_plan_content,pages

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

백업에 오브젝트 스토리지를 사용하는 경우 tar 생성을 건너뛸 수 없습니다.

백업 스크립트가 생성하는 .tar 파일을 원격 스토리지에 업로드하도록 설정할 수 있습니다. 다음 예에서는 Amazon S3를 스토리지로 사용하지만 Google Cloud Storage, Azure와 같은 다른 클라우드 제공업체나 로컬 마운트 공유를 사용할 수도 있습니다.

참고 링크:

• Fog 라이브러리 문서

• 다른 스토리지 제공업체

• GitLab 오브젝트 스토리지 가이드

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

• GitLab에서 오브젝트 스토리지 사용

Amazon S3 사용#

Linux 패키지(Omnibus)의 경우:

• /etc/gitlab/gitlab.rb에 다음을 추가하세요:

gitlab_rails['backup_upload_connection'] = {
  'provider' => 'AWS',
  'region' => 'eu-west-1',
  # 인증 방법 중 하나를 선택하세요
  # IAM 프로필
  'use_iam_profile' => true
  # 또는 AWS 액세스 및 시크릿 키
  'aws_access_key_id' => 'AKIAKIAKI',
  'aws_secret_access_key' => 'secret123'
}
gitlab_rails['backup_upload_remote_directory'] = 'my.s3.bucket'
# 파일 크기가 100 MB에 도달하면 멀티파트 업로드 사용 고려. 바이트 단위로 숫자를 입력하세요.
# gitlab_rails['backup_multipart_chunk_size'] = 104857600

• IAM 프로필 인증 방법을 사용하는 경우, backup-utility가 실행될 인스턴스에 다음 정책이 설정되어 있는지 확인하세요(<backups-bucket>을 올바른 버킷 이름으로 교체):

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Action": [
                "s3:PutObject",
                "s3:GetObject",
                "s3:DeleteObject"
            ],
            "Resource": "arn:aws:s3:::<backups-bucket>/*"
        }
    ]
}

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

S3 암호화 버킷#

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

• Amazon S3 관리형 키(SSE-S3)

• AWS Key Management Service에 저장된 고객 마스터 키(CMK)(SSE-KMS)

• 고객 제공 키(SSE-C)

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

SSE-S3 SSE-S3를 활성화하려면 백업 스토리지 옵션에서 server_side_encryption 필드를 AES256으로 설정하세요. 예를 들어 Linux 패키지(Omnibus)에서:

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

SSE-KMS SSE-KMS를 활성화하려면 arn:aws:kms:region:acct-id:key/key-id 형식의 Amazon Resource Name(ARN)을 통한 KMS 키가 필요합니다. backup_upload_storage_options 구성 설정에서 다음을 설정하세요:

• server_side_encryption을 aws:kms로 설정.

• server_side_encryption_kms_key_id를 키의 ARN으로 설정.

예를 들어 Linux 패키지(Omnibus)에서:

gitlab_rails['backup_upload_storage_options'] = {
  'server_side_encryption' => 'aws:kms',
  'server_side_encryption_kms_key_id' => 'arn:aws::'
}

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

• backup_encryption: AES256.

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

예를 들어 Linux 패키지(Omnibus)에서:

gitlab_rails['backup_encryption'] = 'AES256'
gitlab_rails['backup_encryption_key'] = ''

키에 이진 문자가 포함되어 UTF-8로 인코딩할 수 없는 경우, 대신 GITLAB_BACKUP_ENCRYPTION_KEY 환경 변수를 사용하여 키를 지정하세요. 예를 들면:

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

Digital Ocean Spaces#

이 예는 암스테르담(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 재구성하세요.

Digital Ocean Spaces 사용 시 400 Bad Request 오류 메시지가 표시되면, 백업 암호화 사용이 원인일 수 있습니다. Digital Ocean Spaces는 암호화를 지원하지 않으므로 gitlab_rails['backup_encryption']이 포함된 행을 제거하거나 주석 처리하세요.

다른 S3 제공업체#

모든 S3 제공업체가 Fog 라이브러리와 완전히 호환되는 것은 아닙니다. 예를 들어, 업로드를 시도한 후 411 Length Required 오류 메시지가 표시되면, 이 이슈로 인해 aws_signature_version 값을 기본값에서 2로 다운그레이드해야 할 수 있습니다.

직접 컴파일 설치의 경우:

• home/git/gitlab/config/gitlab.yml을 편집하세요:

  backup:
    # snip
    upload:
      # Fog storage connection settings, see https://fog.github.io/storage/ .
      connection:
        provider: AWS
        region: eu-west-1
        aws_access_key_id: AKIAKIAKI
        aws_secret_access_key: 'secret123'
        # If using an IAM Profile, leave aws_access_key_id & aws_secret_access_key empty
        # ie. aws_access_key_id: ''
        # use_iam_profile: 'true'
      # The remote 'directory' to store your backups. For S3, this would be the bucket name.
      remote_directory: 'my.s3.bucket'
      # Specifies Amazon S3 storage class to use for backups, this is optional
      # storage_class: 'STANDARD'
      #
      # Turns on AWS Server-Side Encryption with Amazon Customer-Provided Encryption Keys for backups, this is optional
      #   'encryption' must be set in order for this to have any effect.
      #   'encryption_key' should be set to the 256-bit encryption key for Amazon S3 to use to encrypt or decrypt.
      #   To avoid storing the key on disk, the key can also be specified via the `GITLAB_BACKUP_ENCRYPTION_KEY` your data.
      # encryption: 'AES256'
      # encryption_key: '<key>'
      #
      #
      # Turns on AWS Server-Side Encryption with Amazon S3-Managed keys (optional)
      # https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html
      # For SSE-S3, set 'server_side_encryption' to 'AES256'.
      # For SS3-KMS, set 'server_side_encryption' to 'aws:kms'. Set
      # 'server_side_encryption_kms_key_id' to the ARN of customer master key.
      # storage_options:
      #   server_side_encryption: 'aws:kms'
      #   server_side_encryption_kms_key_id: 'arn:aws:kms:YOUR-KEY-ID-HERE'

• 변경 사항을 적용하려면 GitLab 재시작하세요.

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',

  ## If you have CNAME buckets (foo.example.com), you might run into SSL issues
  ## when uploading backups ("hostname foo.example.com.storage.googleapis.com
  ## does not match the server certificate"). In that case, uncomment the following
  ## setting. See: 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 스토리지 사용#

gitlab_rails['backup_upload_connection'] = {
 'provider' => 'AzureRM',
 'azure_storage_account_name' => '',
 'azure_storage_access_key' => '',
 'azure_storage_domain' => 'blob.core.windows.net', # Optional
}
gitlab_rails['backup_upload_remote_directory'] = ''

gitlab_rails['backup_upload_connection'] = {
  'provider' => 'AzureRM',
  'azure_storage_account_name' => '',
  'azure_storage_domain' => '' # Optional
}
gitlab_rails['backup_upload_remote_directory'] = ''

  backup:
    upload:
      connection:
        provider: 'AzureRM'
        azure_storage_account_name: ''
        azure_storage_access_key: ''
      remote_directory: ''

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

백업을 위한 커스텀 디렉터리 지정#

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

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

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

원격 스토리지에 백업을 업로드하도록 GitLab을 구성한 경우, SKIP=remote 옵션을 사용하여 원격 스토리지에 백업 업로드를 건너뛸 수 있습니다.

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 디렉터리의 하위 디렉터리. 존재하지 않으면 생성됩니다. tar 파일을 마운트된 디렉터리의 루트에 복사하려면 .을 사용하세요.

마운트 시 local_root 키에 설정된 디렉터리는 다음 중 하나가 소유해야 합니다:

• git 사용자. 따라서 CIFS 및 SMB의 경우 git 사용자의 uid=로 마운트합니다.

• 백업 태스크를 실행하는 사용자. Linux 패키지(Omnibus)의 경우 git 사용자입니다.

파일 시스템 성능이 전체 GitLab 성능에 영향을 줄 수 있으므로, 스토리지에 클라우드 기반 파일 시스템 사용을 권장하지 않습니다.

충돌하는 구성 방지#

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

• gitlab_rails['backup_path'] (직접 컴파일 설치의 경우 backup.path).

• gitlab_rails['backup_upload_connection'].local_root (직접 컴파일 설치의 경우 backup.upload.connection.local_root).

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

이 구성 키들이 같은 위치로 설정되면 업로드 기능이 실패합니다. 이는 업로드 위치에 백업이 이미 존재하기 때문입니다. 이 실패로 인해 업로드 기능이 백업을 삭제하는데, 이는 실패한 업로드 시도 후 남은 잔여 파일로 가정하기 때문입니다.

로컬 마운트 공유에 업로드 구성#

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

# The directory inside the mounted folder to copy backups to
# Use '.' to store them in the root directory
gitlab_rails['backup_upload_remote_directory'] = 'gitlab_backups'

backup:
  upload:
    # Fog storage connection settings, see https://fog.github.io/storage/ .
    connection:
      provider: Local
      local_root: '/mnt/backups'
    # The directory inside the mounted folder to copy backups to
    # Use '.' to store them in the root directory
    remote_directory: 'gitlab_backups'

백업 아카이브 권한#

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

gitlab_rails['backup_archive_permissions'] = 0644 # Makes the backup archives world-readable

backup:
  archive_permissions: 0644 # Makes the backup archives world-readable

일일 백업을 위한 cron 구성#

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

중요: 다음도 반드시 백업하세요:

• GitLab 구성 파일

• SSH 호스트 키

리포지터리와 GitLab 메타데이터를 백업하는 cron 작업을 예약할 수 있습니다.

sudo su -
crontab -e

0 2 * * * /opt/gitlab/bin/gitlab-backup create CRON=1

sudo -u git crontab -e

# Create a full backup of the GitLab repositories and SQL database every day at 2am
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 스팸을 줄이기 위해 권장됩니다. 그러나 백업 문제를 해결할 때는 CRON=1을 --trace로 교체하여 자세한 로그를 남기세요.

로컬 파일의 백업 수명 제한(오래된 백업 정리)#

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

정기 백업이 모든 디스크 공간을 사용하지 않도록 백업의 수명을 제한하는 것이 좋습니다. 다음에 백업 태스크가 실행될 때 backup_keep_time보다 오래된 백업이 정리됩니다.

이 구성 옵션은 로컬 파일만 관리합니다. GitLab은 서드파티 오브젝트 스토리지에 저장된 오래된 파일을 정리하지 않습니다. 사용자에게 파일을 나열하고 삭제할 권한이 없을 수 있기 때문입니다. 오브젝트 스토리지에 적절한 보존 정책을 구성하는 것이 좋습니다.

참고 링크:

• 커스텀 파일명 구성

• 원격 클라우드 스토리지에 백업 업로드

• AWS S3 수명 주기 정책

## Limit backup lifetime to 7 days - 604800 seconds
gitlab_rails['backup_keep_time'] = 604800

backup:
  ## Limit backup lifetime to 7 days - 604800 seconds
  keep_time: 604800

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

PgBouncer 연결을 통해 GitLab을 백업하거나 복원하지 마세요. 이러한 태스크는 PgBouncer를 우회하고 PostgreSQL 기본 데이터베이스 노드에 직접 연결해야 합니다. 그렇지 않으면 GitLab 중단이 발생합니다.

GitLab 백업 또는 복원 태스크가 PgBouncer와 함께 사용되면 다음 오류 메시지가 표시됩니다:

ActiveRecord::StatementInvalid: PG::UndefinedTable

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

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

이는 태스크가 pg_dump를 사용하기 때문에 발생합니다. pg_dump는 null 검색 경로를 설정하고 CVE-2018-1058을 해결하기 위해 모든 SQL 쿼리에 스키마를 명시적으로 포함합니다.

PgBouncer의 트랜잭션 풀링 모드에서는 연결이 재사용되므로, PostgreSQL은 기본 public 스키마를 검색하지 못합니다. 결과적으로, 이 검색 경로 지우기로 인해 테이블과 열이 누락된 것처럼 보입니다.

기술적 참조:

• 스키마 처리 구현

• CVE-2018-1058 세부 정보

PgBouncer 우회#

두 가지 수정 방법이 있습니다:

• 환경 변수를 사용하여 백업 태스크의 데이터베이스 설정을 재정의.

• 노드를 재구성하여 PostgreSQL 기본 데이터베이스 노드에 직접 연결.

환경 변수 재정의

기본적으로 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

예를 들어, Linux 패키지(Omnibus)에서 데이터베이스 호스트와 포트를 192.168.1.10 및 포트 5432로 재정의하려면:

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 바이너리는 Gitaly에서 리포지터리 백업을 생성하고 복원하기 위해 백업 Rake 태스크에서 사용됩니다. 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 데이터를 제외하도록 선택할 수 있습니다.

참고 링크:

• 백업해야 하는 데이터

• PostgreSQL 데이터베이스

• 백업에서 특정 데이터 제외

• 백업 명령

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

• GitLab 인스턴스에 많은 Git 리포지터리 데이터가 있고 GitLab 백업 스크립트가 너무 느린 경우.

• GitLab 인스턴스에 포크된 프로젝트가 많고 정기 백업 태스크가 모든 포크에 대해 Git 데이터를 중복하는 경우.

• GitLab 인스턴스에 문제가 있고 정기 백업 및 가져오기 Rake 태스크를 사용할 수 없는 경우.

Gitaly Cluster(Praefect)는 스냅샷 백업을 지원하지 않습니다.

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

• 이 방법을 사용하여 한 운영 체제에서 다른 운영 체제로 마이그레이션하지 마세요. 소스와 대상의 운영 체제는 가능한 한 유사해야 합니다. 예를 들어, 이 방법으로 Ubuntu에서 RHEL로 마이그레이션하지 마세요.

• 데이터 일관성이 매우 중요합니다. 파일 시스템 전송(예: rsync 사용) 또는 스냅샷을 수행하기 전에 GitLab을 중지하여(sudo gitlab-ctl stop) 메모리의 모든 데이터가 디스크로 플러시되도록 해야 합니다. GitLab은 자체 버퍼, 큐 및 스토리지 레이어를 가진 여러 하위 시스템(Gitaly, 데이터베이스, 파일 스토리지)으로 구성됩니다. GitLab 트랜잭션은 이러한 하위 시스템에 걸쳐 있으며, 트랜잭션의 일부가 디스크에 다른 경로로 기록될 수 있습니다. 라이브 시스템에서 파일 시스템 전송 및 스냅샷 실행은 메모리에 있는 트랜잭션의 일부를 캡처하지 못합니다.

예시: Amazon Elastic Block Store(EBS)

• Amazon AWS에서 Linux 패키지(Omnibus)를 사용하는 GitLab 서버.

• ext4 파일 시스템이 있는 EBS 드라이브가 /var/opt/gitlab에 마운트됨.

• 이 경우 EBS 스냅샷을 찍어 애플리케이션 백업을 만들 수 있습니다.

• 백업에는 모든 리포지터리, 업로드 및 PostgreSQL 데이터가 포함됩니다.

예시: Logical Volume Manager(LVM) 스냅샷 + rsync

• Linux 패키지(Omnibus)를 사용하는 GitLab 서버로 /var/opt/gitlab에 LVM 논리 볼륨이 마운트되어 있음.

• rsync를 사용하여 /var/opt/gitlab 디렉터리를 복제하는 것은 rsync가 실행되는 동안 너무 많은 파일이 변경되어 신뢰할 수 없습니다.

• /var/opt/gitlab을 rsync하는 대신 임시 LVM 스냅샷을 생성하고 읽기 전용 파일 시스템으로 /mnt/gitlab_backup에 마운트합니다.

• 이제 원격 서버에 일관성 있는 복제본을 생성하는 더 오래 실행되는 rsync 작업을 수행할 수 있습니다.

• 복제본에는 모든 리포지터리, 업로드 및 PostgreSQL 데이터가 포함됩니다.

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

리포지터리 데이터를 별도로 백업#

먼저 리포지터리를 건너뛰며 기존 GitLab 데이터를 백업해야 합니다:

sudo gitlab-backup create SKIP=repositories

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

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

• GitLab Geo를 사용하고 Geo 보조 사이트의 리포지터리 데이터에 의존.

• 쓰기를 방지하고 Git 리포지터리 데이터 복사.

• 리포지터리를 읽기 전용으로 표시하여 온라인 백업 생성(실험적).

• Gitaly 스토리지 디스크의 디스크 스냅샷 생성.

디스크 스냅샷#

디스크 스냅샷은 다음과 같은 경우에 사용하는 최선의 노력(best-effort) 백업 전략입니다:

• 일반 GitLab 백업 스크립트를 사용할 수 없는 경우.

• 독립형 Gitaly를 사용하고 있으며, 백업하는 동안 모든 리포지터리를 읽기 전용으로 표시할 수 없는 경우.

• rsync, tar, scp와 같은 다른 백업 전략이 지연 시간을 너무 많이 유발하는 경우.

디스크 스냅샷을 생성하기 전에 GitLab을 읽기 전용 상태로 전환해야 합니다. Git은 파일 시스템 활동에도 불구하고 디스크의 파일이 물리적으로 일관되게 유지되도록 보장합니다. 리포지터리 손상이 발생할 가능성은 낮지만, Gitaly 디스크 스냅샷은 GitLab 애플리케이션이 기대하는 것과 논리적으로 일관되지 않을 가능성이 높습니다. 복원된 Gitaly 스냅샷을 다른 GitLab 구성 요소와 일치시키기는 어렵습니다.

디스크 스냅샷은 독립형 Gitaly 노드에서만 지원됩니다. Gitaly Cluster(Praefect)의 디스크 스냅샷 지원은 이슈 7128에서 추적되고 있습니다.

디스크 스냅샷을 생성하는 방법은 Gitaly 노드가 배포된 위치에 따라 다릅니다. 모든 주요 클라우드 서비스는 라이브 인스턴스에 연결된 디스크의 스냅샷을 생성하는 메커니즘을 제공하므로, 사용 중인 클라우드 제공업체의 문서를 확인하세요.

일부 고객은 각 백업 간격마다 두 개의 디스크 스냅샷을 생성하는 하이브리드 방식을 권장했습니다. 첫 번째 스냅샷은 Gitaly가 트래픽을 활발히 처리하는 동안 생성됩니다. 이 스냅샷은 두 델타 중 더 큰 것을 포함하며 시간이 더 오래 걸립니다. 첫 번째 스냅샷이 생성된 후 GitLab을 유지보수 모드로 전환하고 두 번째 스냅샷을 생성하는데, 이는 훨씬 빠르게 완료됩니다. 이 전략은 다운타임을 줄일 수 있지만, GitLab은 내부적으로 이 방식을 사용하지 않습니다.

디스크 스냅샷에서 복원할 때는 복원된 리포지터리의 무결성을 확인해야 합니다. git-fsck(1)을 사용하여 이 검사를 수행할 수 있습니다. 자세한 내용은 명령줄을 사용하여 검사 실행을 참조하세요.

쓰기를 방지하고 Git 리포지터리 데이터 복사#

Git 리포지터리는 일관성 있게 복사해야 합니다. 동시 쓰기 작업 중에 리포지터리를 복사하면 불일치가 발생할 수 있습니다. 이로 인해 논리적 손상, 누락된 커밋 또는 불완전한 백업 데이터가 발생할 수 있습니다.

Git 리포지터리 데이터에 대한 쓰기를 방지하는 두 가지 방법이 있습니다:

• 유지보수 모드를 사용하여 GitLab을 읽기 전용 상태로 전환.

• 리포지터리를 백업하기 전에 모든 Gitaly 서비스를 중지하여 명시적 다운타임 생성:

sudo gitlab-ctl stop gitaly
# execute git data copy step
sudo gitlab-ctl start gitaly

복사 중인 데이터에 쓰기가 방지되어 있는 한(불일치 및 손상 문제를 방지하기 위해) 어떤 방법으로든 Git 리포지터리 데이터를 복사할 수 있습니다. 선호도와 안전성 순서로 권장 방법은 다음과 같습니다:

• 아카이브 모드, 삭제 및 체크섬 옵션과 함께 rsync 사용, 예를 들어:

rsync -aR --delete --checksum source destination # be extra safe with the order as it will delete existing data if inverted

• 다른 서버나 위치로 전체 리포지터리 디렉터리를 복사하는 tar 파이프 사용.

• sftp, scp, cp 또는 다른 복사 방법 사용.

리포지터리를 읽기 전용으로 표시하여 온라인 백업 생성(실험적)#

인스턴스 전체 다운타임 없이 리포지터리를 백업하는 한 가지 방법은 기본 데이터를 복사하는 동안 프로그래밍 방식으로 프로젝트를 읽기 전용으로 표시하는 것입니다.

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

• 리포지터리는 리포지터리 크기에 비례하는 기간 동안 읽기 전용 상태입니다.

• 각 프로젝트를 읽기 전용으로 표시하는 데 시간이 걸려 백업이 완료되는 데 더 오래 걸리며 불일치가 발생할 수 있습니다. 예를 들어, 백업되는 첫 번째 프로젝트에 대한 마지막 데이터와 마지막으로 백업되는 프로젝트 사이에 날짜 불일치가 발생할 수 있습니다.

• 포크 네트워크는 내부 프로젝트가 백업되는 동안 풀 리포지터리에 대한 잠재적 변경을 방지하기 위해 완전히 읽기 전용이어야 합니다.

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