GitLab 백업은 데이터를 보호하고 재해 복구를 지원합니다.

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

대규모 GitLab 인스턴스의 경우 대안적인 백업 전략에는 다음이 포함됩니다:

• 증분 백업.
• 특정 리포지터리 백업.
• 여러 스토리지 위치에 걸친 백업.

백업에 포함된 데이터#

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

• 데이터베이스 데이터 및 구성
• 계정 및 그룹 설정
• CI/CD 아티팩트 및 작업 로그
• Git 리포지터리 및 LFS 객체
• 외부 머지 리퀘스트 diff
• 패키지 레지스트리 데이터 및 컨테이너 레지스트리 이미지
• 프로젝트 및 그룹 위키
• 프로젝트 레벨 첨부 파일 및 업로드
• Secure Files
• GitLab Pages 콘텐츠
• Terraform 상태
• 스니펫

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

• Mattermost 데이터
• Redis (및 Sidekiq 작업)
• Linux 패키지(Omnibus) / Docker / 소스 컴파일 설치의 오브젝트 스토리지
• 글로벌 서버 훅
• 파일 훅
• GitLab 구성 파일(/etc/gitlab)
• TLS 및 SSH 관련 키와 인증서
• 기타 시스템 파일

간단한 백업 절차#

대략적인 지침으로 1k 참조 아키텍처를 사용하고 데이터가 100GB 미만인 경우 다음 단계를 따르십시오:

1. 백업 명령을 실행합니다.
2. 해당되는 경우 오브젝트 스토리지를 백업합니다.
3. 시스템 구성 파일을 수동으로 백업합니다.

참고 항목:

• 1k 참조 아키텍처
• 백업 명령 세부 정보
• 오브젝트 스토리지 구성
• 구성 파일 가이드

백업 확장#

GitLab 데이터 볼륨이 증가함에 따라 백업 명령 실행에 더 많은 시간이 소요됩니다. Git 리포지터리를 동시에 백업하거나 증분 리포지터리 백업과 같은 백업 옵션이 실행 시간을 줄이는 데 도움이 될 수 있습니다. 어느 시점에서 백업 명령만으로는 실용적이지 않을 수 있습니다. 예를 들어 24시간 이상 걸릴 수 있습니다.

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

일부 경우에는 백업이 확장될 수 있도록 아키텍처 변경이 필요할 수 있습니다.

추가 자료:

• 증분 리포지터리 백업.
• Git 리포지터리 동시 백업.
• 대규모 참조 아키텍처 백업 및 복원.
• 대안적인 백업 전략.
• GitLab 리포지터리 백업 시간 단축에 관한 블로그 포스트.

백업해야 하는 데이터는 무엇인가?#

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

PostgreSQL 데이터베이스#

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

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

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

Gitaly 클러스터(Praefect)는 Gitaly 노드를 관리하기 위한 단일 진실의 원천으로 PostgreSQL 데이터베이스를 사용합니다.

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

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

Git 리포지터리#

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

• 단일 디스크가 있는 머신.
• 단일 마운트 포인트로 마운트된 여러 디스크가 있는 머신(RAID 배열 등).
• LVM 사용.

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

• 소스 코드가 저장되는 프로젝트 리포지터리.
• 위키 콘텐츠가 저장되는 위키 리포지터리.
• 디자인 아티팩트가 인덱싱되는 디자인 리포지터리(자산은 실제로 LFS에 있습니다).

모두 동일한 샤드에 있으며 위키 및 디자인 리포지터리 케이스의 경우 -wiki 및 -design 접미사를 사용하여 동일한 기본 이름을 공유합니다.

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

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

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

블롭#

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

• 특정 위치의 파일 시스템.
• 오브젝트 스토리지 솔루션. 오브젝트 스토리지 솔루션은 다음과 같습니다:
  • Amazon S3 및 Google Cloud Storage와 같은 클라우드 기반.
  • 자체 호스팅 S3 호환 오브젝트 스토리지.
  • 오브젝트 스토리지 호환 API를 노출하는 스토리지 어플라이언스.

오브젝트 스토리지#

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

공급자별 백업 가이드:

• Amazon S3 백업
• Google Cloud Storage Transfer Service
• Google Cloud Storage 객체 버전 관리

참고 항목:

• 백업 명령 세부 정보
• 오브젝트 스토리지 구성

컨테이너 레지스트리#

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

• 특정 위치의 파일 시스템.
• 오브젝트 스토리지 솔루션. 오브젝트 스토리지 솔루션은 다음과 같습니다:
  • Amazon S3 및 Google Cloud Storage와 같은 클라우드 기반.
  • 자체 호스팅 S3 호환 오브젝트 스토리지.
  • 오브젝트 스토리지 호환 API를 노출하는 스토리지 어플라이언스.

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

참고 항목:

• GitLab 컨테이너 레지스트리
• 오브젝트 스토리지 구성

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

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

• Linux 패키지 지침

• GitLab Helm 차트

구성 파일 저장#

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

중간자 공격 경고를 피하기 위해 전체 머신 복원을 수행해야 하는 경우를 대비하여 TLS 키와 인증서(/etc/gitlab/ssl, /etc/gitlab/trusted-certs) 및 SSH 호스트 키도 백업할 수 있습니다.

시크릿 파일을 분실하는 드문 경우에는 시크릿 파일이 분실된 경우를 참조하십시오.

기타 데이터#

GitLab은 Redis를 캐시 저장소와 백그라운드 작업 시스템인 Sidekiq의 지속적 데이터 저장 모두에 사용합니다. 제공된 백업 명령은 Redis 데이터를 백업하지 않습니다. 즉, 백업 명령을 사용하여 일관된 백업을 수행하려면 보류 중이거나 실행 중인 백그라운드 작업이 없어야 합니다.

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

수동 백업 옵션:

• Redis 백업 절차
• Elasticsearch 백업 절차

참고 항목: 백업 명령 세부 정보.

요구 사항#

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

• Linux 패키지를 사용하여 설치한 경우 Rsync가 이미 설치되어 있습니다.
• 소스에서 컴파일하여 설치한 경우 rsync가 설치되어 있는지 확인하고 없으면 설치합니다.

백업 명령#

• 백업 명령은 Linux 패키지(Omnibus) / Docker / 소스 컴파일 설치에서 오브젝트 스토리지의 항목을 백업하지 않습니다.
• 백업 명령은 성능상의 이유로 또는 Patroni 클러스터와 함께 PgBouncer를 사용할 때 추가 매개변수가 필요합니다.
• 백업을 생성된 것과 정확히 동일한 버전 및 유형(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을 호출하기 전에 데이터 파일을 임시 위치에 복사하여 오류를 방지합니다.

부작용은 백업 프로세스가 최대 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 데이터베이스 덤프.
• 블롭, 예를 들어 업로드, 작업 아티팩트, 외부 머지 리퀘스트 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를 사용한 병렬 압축#

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

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

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

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

zstd를 사용한 병렬 압축#

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를 실행하거나 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 파일 생성이 낭비이거나 직접적으로 해로울 수 있으므로 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

서버 사이드 리포지터리 백업 생성#

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

1. Gitaly에서 서버 사이드 백업 대상 구성.
2. 리포지터리 서버 사이드 옵션을 사용하여 백업을 생성합니다. 다음 예시를 참조하십시오.

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

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

증분 리포지터리 백업#

증분 리포지터리 백업은 마지막 백업 이후의 변경 사항만 각 리포지터리의 백업 번들에 패킹하기 때문에 전체 리포지터리 백업보다 빠를 수 있습니다. 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

특정 리포지터리 백업#

REPOSITORIES_PATHS 옵션을 사용하여 특정 리포지터리를 백업할 수 있습니다. 마찬가지로 SKIP_REPOSITORIES_PATHS를 사용하여 특정 리포지터리를 건너뛸 수 있습니다. 두 옵션 모두 프로젝트 또는 그룹 경로의 쉼표로 구분된 목록을 허용합니다. 그룹 경로를 지정하면 그룹 및 하위 그룹의 모든 프로젝트의 모든 리포지터리가 사용한 옵션에 따라 포함되거나 건너뜁니다.

예를 들어 그룹 A(group-a)의 모든 프로젝트에 대한 모든 리포지터리, 그룹 B(group-b/project-c)의 프로젝트 C 리포지터리를 백업하고 그룹 A의 프로젝트 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,pages

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

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

참고 항목:

• Fog 라이브러리 설명서
• 기타 스토리지 공급자
• GitLab 오브젝트 스토리지 가이드
• 로컬로 마운트된 공유에 업로드
• GitLab과 오브젝트 스토리지 사용

Amazon S3 사용#

Linux 패키지(Omnibus)의 경우:

1. /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'
   # 파일 크기가 100MB에 도달하면 멀티파트 업로드 사용 고려. 바이트 단위로 숫자를 입력합니다.
   # gitlab_rails['backup_multipart_chunk_size'] = 104857600
   

2. 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>/*"
           }
       ]
   }
   

3. 변경 사항을 적용하려면 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)의 버킷에 사용할 수 있습니다:

1. /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'
   

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

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

기타 S3 공급자#

일부 S3 공급자는 Fog 라이브러리와 완전히 호환되지 않습니다. 예를 들어 업로드를 시도한 후 411 Length Required 오류 메시지가 표시되는 경우 이 이슈로 인해 aws_signature_version 값을 기본값에서 2로 다운그레이드해야 할 수 있습니다.

소스에서 컴파일한 설치의 경우:

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

     backup:
       # snip
       upload:
         # Fog 스토리지 연결 설정, https://fog.github.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'
         #
         # 백업에 Amazon 고객 제공 암호화 키로 AWS 서버 사이드 암호화를 켭니다. 선택 사항입니다.
         #   '암호화'를 설정해야 효과가 있습니다.
         #   'encryption_key'는 Amazon S3가 암호화 또는 복호화에 사용할 256비트 암호화 키로 설정해야 합니다.
         #   디스크에 키 저장을 피하려면 `GITLAB_BACKUP_ENCRYPTION_KEY`로 키를 지정할 수도 있습니다.
         # encryption: 'AES256'
         # encryption_key: '<key>'
         #
         #
         # Amazon S3 관리형 키로 AWS 서버 사이드 암호화를 켭니다(선택 사항).
         # https://docs.aws.amazon.com/AmazonS3/latest/userguide/serv-side-encryption.html
         # SSE-S3의 경우 'server_side_encryption'을 'AES256'으로 설정합니다.
         # SS3-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'
   

2. 변경 사항을 적용하려면 GitLab을 재시작합니다.

Google Cloud Storage 사용#

Google Cloud Storage를 사용하여 백업을 저장하려면 먼저 Google 콘솔에서 액세스 키를 만들어야 합니다:

1. Google 스토리지 설정 페이지로 이동합니다.
2. Interoperability를 선택하고 액세스 키를 만듭니다.
3. Access Key와 Secret을 기록하고 다음 구성에서 교체합니다.
4. 버킷 고급 설정에서 Set object-level and bucket-level permissions 액세스 제어 옵션이 선택되어 있는지 확인합니다.
5. 이미 버킷을 만들었는지 확인합니다.

Linux 패키지(Omnibus)의 경우:

1. /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
     ## does not match the server certificate"). 이 경우 다음 설정의 주석을 해제합니다.
     ## 참조: https://github.com/fog/fog/issues/2834
     #'path_style' => true
   }
   gitlab_rails['backup_upload_remote_directory'] = 'my.google.bucket'
   

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

소스에서 컴파일한 설치의 경우:

1. 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'
   

2. 변경 사항을 적용하려면 GitLab을 재시작합니다.

Azure Blob 스토리지 사용#

자세한 내용은 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 디렉터리의 하위 디렉터리. 존재하지 않으면 생성됩니다. tarball을 마운트된 디렉터리의 루트에 복사하려면 .를 사용합니다.

마운트된 경우 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이 생성한 백업 아카이브(1393513186_2014_02_27_gitlab_backup.tar)는 기본적으로 소유자/그룹 git/git 및 0600 권한을 가집니다. 이는 다른 시스템 사용자가 GitLab 데이터를 읽는 것을 방지하기 위한 것입니다. 백업 아카이브에 다른 권한이 필요한 경우 archive_permissions 설정을 사용할 수 있습니다.

일일 백업을 위한 cron 구성#

중요: 다음도 백업해야 합니다:

• GitLab 구성 파일
• SSH 호스트 키

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

CRON=1 환경 설정은 오류가 없는 경우 백업 스크립트가 모든 진행 출력을 숨기도록 지시합니다. cron 스팸을 줄이기 위해 권장됩니다. 그러나 백업 문제를 해결할 때는 CRON=1 대신 --trace를 사용하여 상세하게 로깅합니다.

로컬 파일의 백업 수명 제한(이전 백업 정리)#

일반 백업이 모든 디스크 공간을 사용하지 않도록 백업의 수명 제한을 설정할 수 있습니다. 다음에 백업 작업이 실행되면 backup_keep_time보다 오래된 백업이 정리됩니다.

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

참고 항목:

• 사용자 정의 파일 이름 구성
• 원격 클라우드 스토리지에 백업 업로드
• AWS S3 수명 주기 정책

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 우회#

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

1. 환경 변수를 사용하여 백업 작업의 데이터베이스 설정을 재정의합니다.
2. 노드를 재구성하여 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 바이너리는 백업 Rake 작업에서 Gitaly의 리포지터리 백업을 생성하고 복원하는 데 사용됩니다. gitaly-backup은 Gitaly에서 GitLab이 RPC를 직접 호출하는 이전 백업 방법을 대체합니다.

백업 Rake 작업은 이 실행 파일을 찾을 수 있어야 합니다. 대부분의 경우 기본 경로 /opt/gitlab/embedded/bin/gitaly-backup으로 정상 작동하므로 바이너리 경로를 변경할 필요가 없습니다. 변경할 특정 이유가 있는 경우 Linux 패키지(Omnibus)에서 구성할 수 있습니다:

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

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

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

대안적인 백업 전략#

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

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

참고 항목:

• 백업해야 하는 데이터는 무엇인가
• PostgreSQL 데이터베이스
• 백업에서 특정 데이터 제외
• 백업 명령

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

• GitLab 인스턴스에 많은 Git 리포지터리 데이터가 있고 GitLab 백업 스크립트가 너무 느린 경우.
• GitLab 인스턴스에 많은 포크된 프로젝트가 있고 일반 백업 작업이 모든 프로젝트의 Git 데이터를 복제하는 경우.
• GitLab 인스턴스에 문제가 있어 일반 백업 및 가져오기 Rake 작업을 사용할 수 없는 경우.

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

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

예시: Amazon Elastic Block Store(EBS)

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

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

• LVM 논리 볼륨이 /var/opt/gitlab에 마운트된 Linux 패키지(Omnibus)를 사용하는 GitLab 서버.
• rsync가 실행되는 동안 너무 많은 파일이 변경되기 때문에 /var/opt/gitlab 디렉터리를 rsync로 복제하는 것은 신뢰할 수 없습니다.
• /var/opt/gitlab를 rsync하는 대신 /mnt/gitlab_backup에 읽기 전용 파일 시스템으로 마운트하는 임시 LVM 스냅샷을 만듭니다.
• 이제 원격 서버에 일관된 복제본을 만드는 더 오랜 시간이 걸리는 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 리포지터리 데이터를 수동으로 백업하는 방법에는 여러 가지가 있습니다:

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

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

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

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

• 유지 관리 모드를 사용하여 GitLab을 읽기 전용 상태로 설정합니다.

• 모든 Gitaly 서비스를 중지하여 명시적인 다운타임을 만들고 리포지터리를 백업합니다:

  sudo gitlab-ctl stop gitaly
  # git 데이터 복사 단계 실행
  sudo gitlab-ctl start gitaly
  

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

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

   rsync -aR --delete --checksum source destination # 순서가 뒤집히면 기존 데이터를 삭제하므로 더욱 안전하게 주의하십시오
   

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

3. sftp, scp, cp 또는 다른 복사 방법을 사용합니다.

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

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

몇 가지 가능한 단점이 있습니다:

• 리포지터리는 리포지터리 크기에 따라 확장되는 기간 동안 읽기 전용입니다.
• 각 프로젝트를 읽기 전용으로 표시하는 데 시간이 걸려 불일치를 초래할 수 있어 백업에 더 많은 시간이 소요됩니다. 예를 들어 백업되는 첫 번째 프로젝트에 대해 마지막으로 백업되는 프로젝트에 비해 마지막 가용 데이터 간에 날짜 불일치가 발생할 수 있습니다.
• 내부 프로젝트의 포크 네트워크는 풀 리포지터리에 대한 잠재적 변경을 방지하기 위해 백업되는 동안 완전히 읽기 전용이어야 합니다.

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