• 간단한 백업 절차
• 백업 확장
• 백업이 필요한 데이터는 무엇인가요?
  • PostgreSQL 데이터베이스
  • Git 리포지터리
  • Blobs
    • 객체 리포지터리
  • 컨테이너 레지스트리
  • 구성 파일 저장
  • 기타 데이터
• Command-line interface
  • 요구 사항
  • 백업 명령어
  • 백업 옵션
    • 백업 전략 옵션
    • 백업 파일명
    • 백업 압축
      • 기본 압축: Gzip 및 가장 빠른 방법
      • 가장 느린 방법으로 Gzip
      • 압축 없음
      • pigz로 병렬 압축
      • zstd로 병렬 압축
    • 전송 가능한 아카이브 확인
    • 백업에서 특정 데이터 제외하기
    • tar 생성 건너뛰기
    • 서버 측 리포지터리 백업 생성
    • Git 리포지터리 동시에 백업하기
    • 증분 리포지터리 백업
    • 특정 리포지터리 스토리지 백업
    • 특정 리포지터리 백업
    • 원격(클라우드) 리포지터리로 백업 업로드
      • Amazon S3 사용
      • S3 암호화된 버킷
      • Digital Ocean Spaces
      • 다른 S3 제공업체
      • Google Cloud Storage 사용
      • Azure Blob 리포지터리 사용
      • 백업용 사용자 정의 디렉터리 지정
    • 원격 리포지터리로의 백업 업로드 건너뛰기
    • 로컬로 마운트된 공유물에 업로드하기
      • 충돌하는 구성을 피하기
      • 로컬로 마운트된 공유물에 업로드 구성하기
    • 백업 아카이브 권한
    • 매일 백업하기 위한 cron 설정
    • 로컬 파일의 백업 수명 제한하기(이전 백업 정리)
    • PgBouncer 사용 설치의 백업 및 복원
      • PgBouncer 우회 방법
    • 리포지터리 백업 및 복원을 위한 gitaly-backup
• 대체 백업 전략
  • 리포지터리 데이터 별도로 백업
    • 쓰기 방지 및 Git 리포지터리 데이터 복사
    • 리포지터리를 읽기 전용으로 표시하여 온라인 백업 (실험적)

GitLab 백업

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

간단한 백업 절차

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

1. 백업 명령 실행.
2. 해당 사항이 있는 경우 객체 리포지터리 백업.
3. 구성 파일을 매뉴얼으로 백업.

백업 확장

GitLab 데이터 양이 증가함에 따라 백업 명령의 실행 시간도 증가합니다. 백업 옵션인 Git 리포지터리를 병행하여 백업 및 증분 리포지터리 백업은 실행 시간을 줄이는 데 도움이 될 수 있습니다. 어느 정도되면 백업 명령은 단독으로 실용적이지 않게 됩니다. 예를 들어 24시간 이상 소요될 수 있습니다.

일부 경우에는 백업을 확장하기 위해 아키텍처 변경이 필요할 수 있습니다. GitLab 레퍼런스 아키텍처를 사용하는 경우, 대용량 레퍼런스 아키텍처 백업 및 복원을 참조하세요.

더 많은 정보는 대안적 백업 전략을 참조하세요.

백업이 필요한 데이터는 무엇인가요?

• PostgreSQL 데이터베이스
• Git 리포지터리
• Blobs
• 컨테이너 레지스트리
• 구성 파일
• 기타 데이터

PostgreSQL 데이터베이스

가장 간단한 경우에 GitLab은 웹 인터페이스에서 사용자가 생성한 대부분의 콘텐츠에 대한 진실한 단일 원본인 PostgreSQL 데이터베이스를 하나 보유하고 있습니다. 그러나 구성에 따라 GitLab은 여러 PostgreSQL 데이터베이스를 여러 PostgreSQL 서버에서 사용할 수도 있습니다.

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

PostgreSQL은 HTML로 렌더링된 마크다운과 기본적으로 Merge Request 차이를 보관하기도 합니다. 그러나 Merge Request 차이는 파일 시스템이나 객체 리포지터리로 오프로드되도록 구성할 수도 있습니다. Blobs 참조.

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

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

불행하게도 데이터베이스가 크면 pg_dump가 실행되는 데 더 오래 걸립니다. 상황에 따라 실행 속도가 어느 정도 되면 (예: 몇 일), 사용이 불가능해집니다. 데이터베이스가 100GB를 넘는 경우, pg_dump 및 여기서 파생된 백업 명령을 사용하는 것이 불가능할 가능성이 높습니다. 대안적 백업 전략을 참조하세요.

Git 리포지터리

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

• 단일 디스크를 사용합니다.
• 하나의 마운트 지점으로 마운트된 여러 디스크를 사용합니다 (RAID 배열과 같이).
• LVM을 사용합니다.

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

• 프로젝트 리포지터리, 소스 코드가 저장되는 곳입니다.
• 위키 리포지터리, 위키 콘텐츠가 저장되는 곳입니다.
• 디자인 리포지터리, 디자인 자산이 색인되는 곳입니다 (실제 자산은 LFS에 있습니다).

모두 동일한 샤드에 존재하며 위키 및 디자인 리포지터리에는 -wiki 및 -design 접미사가 있습니다.

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

풀 리포지터리를 사용하여 프로젝트 포크를 실시간으로 중복 제거합니다.

백업 명령은 각 리포지터리에 대해 Git 번들을 생성하여 그들을 모두 tar로 묶습니다. 이로 인해 풀 리포지터리 데이터가 모든 포크에 중복됩니다. 우리의 실험에서 100GB의 Git 리포지터리는 백업 및 S3로 업로드하는 데 약 2시간이 조금 넘게 걸렸습니다. 약 400GB의 Git 데이터에서는 백업 명령이 정기적인 백업에는 사용되기 어려울 가능성이 높습니다. 대안적 백업 전략을 참조하세요.

Blobs

GitLab은 이슈 첨부 파일이나 LFS 객체와 같은 blobs(또는 파일)를 특정 위치의 파일 시스템 또는 객체 리포지터리에 저장합니다. 객체 리포지터리 솔루션은 다음과 같을 수 있습니다:

• Amazon S3 및 Google Cloud Storage와 같은 클라우드 기반 솔루션.
• MinIO와 같이 사용자가 호스팅하는 솔루션.
• 객체 리포지터리 호환 API를 노출하는 스토리지 장치.

객체 리포지터리

백업 명령은 파일 시스템에 저장되지 않은 blobs를 백업하지 않습니다. 객체 리포지터리를 사용하는 경우, 해당 객체 리포지터리 공급업체와 백업을 활성화해야 합니다. 예를 들어 다음을 참조하세요:

• Amazon S3 백업
• Google Cloud Storage 전송 서비스 및 Google Cloud Storage 객체 버전 관리

컨테이너 레지스트리

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

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

• 객체 리포지터리 솔루션. 객체 리포지터리 솔루션은 다음과 같을 수 있습니다:

  • Amazon S3 및 Google Cloud Storage와 같은 클라우드 기반 솔루션.
  • MinIO와 같이 사용자가 호스팅하는 솔루션.
  • 객체 리포지터리 호환 API를 노출하는 스토리지 장치.

백업 명령은 파일 시스템의 기본 위치에 저장될 때 레지스트리 데이터를 백업합니다.

구성 파일 저장

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

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

시크릿 파일이 분실되면, 시크릿 파일이 분실된 경우을 참조하세요.

기타 데이터

GitLab은 Redis를 캐시 스토어로 사용하고 백그라운드 작업 시스템 Sidekiq의 지속적인 데이터를 보유하기 위해서 사용합니다. 제공된 백업 명령은 Redis 데이터를 백업하지 않습니다. 따라서 백업 명령을 사용하여 일관된 백업을 수행하려면 보류 중이거나 실행 중인 백그라운드 작업이 없어야 합니다. 매뉴얼으로 Redis를 백업하는 것도 가능합니다.

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

Command-line interface

GitLab은 전체 인스턴스를 백업하기 위한 명령줄 인터페이스를 제공합니다. 이는 다음과 같은 것들을 포함합니다:

• 데이터베이스
• 첨부 파일
• Git 리포지터리 데이터
• CI/CD 작업 출력 로그
• CI/CD 작업 아티팩트
• LFS 객체
• Terraform 상태
• 컨테이너 레지스트리 이미지
• GitLab 페이지 콘텐츠
• 패키지
• 코드 조각
• 그룹 위키
• 프로젝트별 보안 파일 (소개됨 - GitLab 16.1에서)
• Merge Request 차이점 (Helm 차트 설치에서만)

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

• Mattermost 데이터
• Redis (따라서 Sidekiq 작업도 제외됨)
• 리눅스 패키지 (Omnibus) / Docker / 자체 컴파일 설치의 객체 리포지터리

요구 사항

백업 및 복원을 하려면 시스템에 Rsync가 설치되어 있는지 확인하세요. 만약 GitLab을 다음과 같은 방법으로 설치했다면:

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

• 자체로 컴파일했다면, rsync가 설치되어 있는지 확인하세요. 설치되어 있지 않다면 다음과 같이 설치하세요:

  # Debian/Ubuntu
  sudo apt-get install rsync
    
  # RHEL/CentOS
  sudo yum install rsync
  

백업 명령어

GitLab이 생성된 시스템에서 백업합니다.

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의 명령줄 도구는 더 많은 옵션을 받아들일 수 있습니다.

백업 전략 옵션

기본 백업 전략은 리눅스 명령어 tar 및 gzip를 사용하여 해당 데이터 위치에서 데이터를 백업으로 스트리밍하는 것입니다. 이것은

대부분의 경우에는 정상적으로 작동하지만, 데이터가 빠르게 변경될 때 문제가 발생할 수 있습니다.

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

부작용은 백업 프로세스가 추가 1X 디스크 공간을 차지할 수 있다는 것입니다. 프로세스는 각 단계에서 임시 파일을 정리하기 위해 최선을 다하지만, 큰 설치에서는 상당한 변화일 수 있습니다.

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

sudo gitlab-backup create STRATEGY=copy

백업 파일명

백업 파일은 특정 기본값에 따라 파일명이 생성됩니다. 그러나 BACKUP 환경 변수를 설정하여 파일명의 <백업 ID> 부분을 재정의할 수 있습니다. 예를 들면:

sudo gitlab-backup create BACKUP=dump

그 결과 파일은 dump_gitlab_backup.tar로 이름이 지정됩니다. 이는 rsync 및 점진적 백업을 사용하는 시스템에 유용하며 전송 속도가 상당히 빨라집니다.

백업 압축

기본적으로 Gzip 고속 압축이 다음과 같은 백업에 적용됩니다:

• PostgreSQL 데이터베이스 덤프.
• blobs, 예를 들면 업로드, 작업 아티팩트, 외부 Merge Request 차이 파일.

기본 명령어는 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로 병렬 압축

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

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를 사용하여 4개의 스레드로 백업을 압축하는 예시:

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 옵션을 설정할 수 있습니다. 이는 --rsyncable 옵션을 gzip에 설정하는 것으로, 백업 파일 이름 옵션과 함께 사용될 때 유용합니다.

gzip의 --rsyncable 옵션이 모든 배포에서 사용 가능한 것은 아닙니다. 귀하의 배포에서 사용 가능한지 확인하려면 gzip --help를 실행하거나 매뉴얼 페이지를 참조하세요.

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

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

• GitLab 16.3에 도입됨.
• GitLab 16.6에 가장 최근 백업 대신 지정된 백업을 복원하는 서버 측 지원 도입됨.
• GitLab 16.6에 증분 백업 생성을 위한 서버 측 지원 도입됨.

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

1. Gitaly에서 서버 측 백업 대상 구성.
2. REPOSITORIES_SERVER_SIDE 변수를 사용하여 백업을 생성하세요. 다음 예시를 참조하세요.

sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true

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

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에서 도입.

증분 리포지터리 백업은 각 리포지터리의 마지막 백업 이후의 변경 사항 만을 백업 번들에 포장하므로 전체 리포지터리 백업보다 빠를 수 있습니다. 증분 백업 아카이브는 서로 연결되어 있지 않습니다: 각 아카이브는 인스턴스의 독립적인 백업입니다. 증분 백업을 생성하려면 기존 백업이 있어야 합니다.

PREVIOUS_BACKUP=<백업-id> 옵션을 사용하여 사용할 백업을 선택하세요. 기본적으로 백업 파일은 백업 ID 섹션에 문서화된대로 만들어집니다. BACKUP 환경 변수를 설정하여 파일 이름의 <백업-id> 부분을 재정의할 수 있습니다.

증분 백업을 만들려면 다음과 같이 실행하세요:

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

tar된 백업에서 untarred 증분 백업을 만들려면 SKIP=tar를 사용하세요:

sudo gitlab-backup create INCREMENTAL=yes SKIP=tar

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

• GitLab 15.0에서 도입됨(https://gitlab.com/gitlab-org/gitlab/-/merge_requests/86896).

여러 리포지터리 스토리지를 사용할 때, 특정 리포지터리 스토리지의 리포지터리는 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 15.1에서 도입됨(https://gitlab.com/gitlab-org/gitlab/-/merge_requests/88094).
• 특정 리포지터리 건너뛰기가 추가됨(https://gitlab.com/gitlab-org/gitlab/-/merge_requests/121865) in GitLab 16.1.

REPOSITORIES_PATHS 옵션을 사용하여 특정 리포지터리를 백업할 수 있습니다. 마찬가지로 SKIP_REPOSITORIES_PATHS를 사용하여 특정 리포지터리를 건너뛸 수 있습니다. 두 옵션 모두 프로젝트 또는 그룹 경로의 쉼표로 구분된 디렉터리을 허용합니다. 그룹 경로를 지정하면 그룹 및 하위 그룹의 모든 프로젝트의 모든 리포지터리가 포함되거나 건너뛰어진다는 점을 주의하세요.

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

원격(클라우드) 리포지터리로 백업 업로드

아래 예에서는 리포지터리로 Amazon S3를 사용하지만 Fog를 사용하면 다른 리포지터리 제공업체를 사용할 수 있습니다. GitLab은 또한 AWS, Google 및 Aliyun에 대한 클라우드 드라이버를 가져올 수 있습니다. 로컬 드라이버도 사용 가능합니다.

GitLab과 객체 리포지터리를 사용에 대해 자세히 알아보기.

Amazon S3 사용

리눅스 패키지(Omnibus)에서:

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

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

S3 암호화된 버킷

AWS는 서버 측 암호화에 대해 다음과 같은 모드를 지원합니다:

• Amazon S3 관리 키 (SSE-S3)
• AWS 키 관리 서비스(AWS KMS)에 저장된 고객 마스터 키(CMKs) (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를 활성화하려면, backup_upload_storage_options 구성 설정 아래에서 KMS 키를 arn:aws:kms:region:acct-id:key/key-id 형식으로 제공해야 합니다. 아래와 같이 설정하세요:

• 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 }

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.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 S3 서버 측 암호화(AWS Server-Side Encryption)를 켜려면, 이 부분은 선택 사항입니다.
         #   'encryption'은 이 영향을 미치려면 설정되어야 합니다.
         #   'encryption_key'는 Amazon S3가 암호화 또는 해독하는 데 사용할 256비트 암호화 키여야 합니다.
         #   디스크에 키를 저장하지 않으려면, 키는 `GITLAB_BACKUP_ENCRYPTION_KEY`를 통해 지정할 수도 있습니다.
         # encryption: 'AES256'
         # encryption_key: '<key>'
         #
         #
         # Amazon S3-Managed 키로 Amazon S3 서버 측 암호화를 켜려면(선택 사항)
         # 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 재시작을 수행하세요

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 콘솔에서 액세스 키를 생성해야 합니다:

1. Google 리포지터리 설정 페이지로 이동합니다.
2. 상호 운용성을 선택하고, 액세스 키를 생성하세요.
3. 액세스 키와 비밀을 확인하고 다음 구성에서 해당 값으로 교체하세요.
4. 고급 설정에서 액세스 제어 옵션 중 객체 수준 및 버킷 수준 권한 설정을 선택하세요.
5. 이미 버킷을 만들어두었는지 확인하세요.

리눅스 패키지(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 문제가 발생할 수 있습니다 ("호스트 이름 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'
   

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를 사용하여 (NFS, CIFS, 또는 SMB와 같은) 로컬로 마운트된 공유물에 백업을 전송할 수 있습니다. Local 스토리지 제공자를 사용합니다.

이를 위해 다음 구성 키를 설정해야 합니다.

• 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이 생성한 백업 아카이브(1393513186_2014_02_27_gitlab_backup.tar) 는 기본적으로 소유주/그룹이 git/git이며 기본적으로 0600 권한을 가지고 있습니다. 다른 시스템 사용자가 GitLab 데이터를 읽는 것을 피하기 위한 것입니다. 백업 아카이브에 다른 권한을 부여해야 하는 경우 archive_permissions 설정을 사용할 수 있습니다.

매일 백업하기 위한 cron 설정

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

sudo su -
crontab -e

CRON=1 환경 설정은 오류가 없는 경우 모든 진행 상황을 숨기도록 백업 스크립트에 지시합니다. 이는 크론 스팸을 줄이기 위해 권장되는 사항입니다. 그러나 백업 문제를 해결할 때는 CRON=1을 --trace로 바꿔 자세한 내용을 기록하세요.

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

정기적인 백업이 디스크 공간을 모두 사용하는 것을 막으려면 백업의 제한된 수명을 설정할 수 있습니다. 다음 번 백업 작업 실행 시 backup_keep_time보다 오래된 백업은 정리됩니다.

이 구성 옵션은 로컬 파일만 관리합니다. GitLab은 사용자가 디렉터리 및 삭제 권한을 갖고 있지 않을 수 있기 때문에 제3자 객체 리포지터리에 저장된 오래된 파일을 정리하지 않습니다. 각 객체 리포지터리에 적절한 보존 정책을 구성하는 것이 권장됩니다(예: 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를 사용하기 때문인데, 이는 CVE-2018-1058을 해결하기 위해 검색 경로를 널로 설정하고 모든 SQL 쿼리에 명시적으로 스키마를 포함합니다.

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

PgBouncer 우회 방법

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

1. 백업 작업을 위해 데이터베이스 설정을 재정의하려면 환경 변수를 사용하세요.
2. 노드를 직접 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

예를 들어 Linux package (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은 이전에 GitLab에서 Gitaly의 RPC를 직접 호출하는 백업 방법을 대체합니다.

백업 Rake 작업은 이 실행 파일을 찾을 수 있어야 합니다. 대부분의 경우 기본 경로 /opt/gitlab/embedded/bin/gitaly-backup으로 정상 작동해야 할 것입니다. 경로를 변경해야 하는 구체적인 이유가 있는 경우 Linux package (Omnibus)에서 구성할 수 있습니다:

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

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

2. 변경 사항이 적용되려면 GitLab 재구성을 해야 합니다.

대체 백업 전략

모든 배포는 다양한 기능을 갖고 있을 수 있으므로 백업해야 할 데이터를 먼저 검토하여 해당 데이터를 저장하고 어떻게 활용할 수 있는지 확인해야 합니다.

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

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

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

파일 시스템 데이터 전송 또는 스냅숏을 사용할 때 다음을 고려하세요:

• 이러한 방법을 사용하여 한 운영 체제에서 다른 운영 체제로 마이그레이션하지 마세요. 원본 및 대상 운영 체제는 가능한 한 유사해야 합니다. 예를 들어, Ubuntu에서 RHEL로 마이그레이션하는 것은 이 방법을 사용하지 않아야 합니다.
• 데이터 일관성은 매우 중요합니다. 파일 시스템 전송(rsync 예를 들어) 또는 스냅숏을 촬영하기 전에 GitLab을 중지해야 합니다.

예시: Amazon Elastic Block Store (EBS)

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

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

• Linux package (Omnibus)를 사용하는 GitLab 서버, /var/opt/gitlab에 마운트된 LVM 논리 볼륨을 사용
• /var/opt/gitlab 디렉터리를 rsync로 복제하는 것은 실행 중에 너무 많은 파일이 변경되기 때문에 신뢰성이 없습니다.
• 대신에 /var/opt/gitlab을 rsync하는 대신 일관된 레플리카를 생성하기 위해 임시 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 리포지터리는 일관된 방식으로 복사되어야 합니다. 동시에 쓰기 작업 중에 복사해서는 안 되며, 이는 불일치나 훼손 문제를 야기할 수 있습니다. 자세한 내용은 issue #270422 에서 잠재적 문제에 대해 논의되었습니다.

Git 리포지터리 데이터에 대한 쓰기를 방지하기 위해 두 가지 가능한 접근 방법이 있습니다:

• GitLab을 읽기 전용 상태로 두기 위해 유지 보수 모드 사용

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

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

데이터를 복사할 때는 불일치와 훼손 문제를 방지하기 위해 데이터에 쓰기 작업이 방지될 수 있다면 실제 데이터 복사 방법에 상관없이 복사할 수 있습니다. 우선적으로 권장되는 방법은 다음과 같습니다:

1. 아카이브 모드, 삭제 및 체크섬 옵션을 사용한 rsync 사용, 예를 들어:

   rsync -aR --delete --checksum source destination # 기존 데이터 삭제에 대비하여 순서를 신중히 선택하세요
   

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

3. sftp, scp, cp 또는 기타 복사 방법 사용

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

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

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

• 리포지터리는 리포지터리 크기에 비례하여 일정 기간 동안 읽기 전용이 됩니다.
• 리포지터리를 읽기 전용으로 표시하는 시간이 길어져 백업이 늦어질 수 있으며, 이는 불일치를 야기할 수 있습니다. 예를 들어, 첫 번째 백업을 받는 프로젝트와 마지막으로 백업 받는 프로젝트 사이에 가능한 날짜 이질이 있을 수 있습니다.
• 포크 네트워크는 잠재적으로 풀 리포지터리에 대한 변화를 방지하기 위해 내부 프로젝트가 백업되는 동안 완전히 읽기 전용이어야 합니다.

이 프로세스를 자동화하려는 실험적 스크립트가 있으며, Geo 팀 Runbooks 프로젝트에서 이를 시도해보실 수 있습니다.