• 매일 백업 구성
  • PostgreSQL 데이터 백업 구성
  • 객체 저장소 데이터 백업 구성
  • Git 저장소의 백업 구성
  • 구성 파일의 백업 구성
• 백업 복원
  • 사전 요구 사항
  • 객체 저장소 데이터 복원
  • PostgreSQL 데이터 복원
  • Git 저장소 복원

대규모 참조 아키텍처의 백업 및 복원

이 문서는 다음을 설명합니다.

• 매일 백업 구성
• 지금 백업 가져가기 (계획됨)
• 백업 복원

이 문서는 다음 환경을 사용하는 대상을 대상으로 합니다.

• 리눅스 패키지(Omnibus) 및 클라우드 네이티브 하이브리드 참조 아키텍처 3,000 사용자 이상
• Amazon RDS에서 PostgreSQL 데이터
• Amazon S3에서 객체 저장
• 객체 저장소에서 가능한 모든 것, 포함하여 블롭 및 컨테이너 레지스트리

매일 백업 구성

PostgreSQL 데이터 백업 구성

백업 명령은 pg_dump를 사용하며, 이는 100GB 이상의 데이터베이스에 적합하지 않습니다. 원활하고 튼튼한 백업 기능을 갖춘 PostgreSQL 솔루션을 선택해야 합니다.

객체 저장소 데이터 백업 구성

객체 저장소(NFS가 아님)는 블롭 및 컨테이너 레지스트리를 포함한 GitLab 데이터를 저장하기에 권장됩니다.

Git 저장소의 백업 구성

Cloud 네이티브 하이브리드를 사용하는 경우, GitLab Linux 패키지를 실행하는 VM을 프로비저닝하세요.

1. 8 vCPU 및 7.2GB 메모리가 있는 VM을 실행합니다. 이 노드는 Git 저장소를 백업하는 데 사용될 것입니다. backup-utility에 Gitaly 서버 측 백업 지원을 추가하는 것이 제안되었으며 이는 issue 438393에서 확인할 수 있습니다. 이로써 VM을 프로비저닝할 필요가 없어질 것입니다.
2. 또 다른 GitLab Rails 노드로서 이 노드를 귀사의 참조 아키텍처에서 정의된 것과 같이 구성하세요. 다른 GitLab Rails 노드와 마찬가지로 이 노드는 귀사의 주 PostgreSQL 데이터베이스, Redis, 객체 저장소 및 Gitaly 클러스터에 액세스해야 합니다. 리퍼런스 아키텍처에서 서버를 설정하는 예제를 보려면 GitLab Rails 구성 섹션을 참조하세요. Linux 패키지 설치를 위한 동등한 Helm 차트 값을 번역해야 할 수도 있습니다. Praefect 노드는 Git 데이터를 백업하는 데 사용할 수 없습니다. GitLab Rails 노드여야 합니다.

3. 이 노드에서 GitLab 애플리케이션이 실행되지 않도록 하기 위해 대부분의 서비스를 비활성화하세요:

   1. /etc/gitlab/gitlab.rb를 편집하여 다음 서비스가 비활성화되었는지 확인합니다. roles(['application_role'])은 Redis, PostgreSQL, 그리고 Consul을 비활성화하며, 참조 아키텍처 Rails 노드 정의의 기초입니다.

       roles(['application_role'])
       gitlab_workhorse['enable'] = false
       puma['enable'] = false
       sidekiq['enable'] = false
       gitlab_kas['enable'] = false
       gitaly['enable'] = false
       prometheus_monitoring['enable'] = false
      

   2. GitLab을 다시 구성하세요:

       sudo gitlab-ctl reconfigure
      

   3. 남아 있는 유일한 서비스는 logrotate여야 합니다. logrotate만 남아 있는지 확인하려면 다음 명령을 실행하세요:

       gitlab-ctl status
      

   Linux 패키지에 이러한 요구 사항을 충족하는 역할을 추가하는 것이 제안되었습니다(Issue 6823).

Git 저장소를 백업하려면:

1. 모든 Gitaly 노드에서 서버 측 백업 대상을 구성하세요.
2. 객체 저장소 데이터의 백업에 대상 버킷을 추가하세요.

3. Git 데이터의 전체 백업을 수행하세요. REPOSITORIES_SERVER_SIDE 변수를 사용하고 PostgreSQL 데이터를 건너뛰세요:

    sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db
   

   이로써 Gitaly 노드는 Git 데이터 및 일부 메타데이터를 원격 저장소에 업로드합니다. 업로드, 아티팩트 및 LFS와 같은 블롭은 명시적으로 건너뛰지 않아도 됩니다. 바로 gitlab-backup 명령은 기본적으로 객체 저장소를 백업하지 않기 때문입니다.

4. 백업의 백업 ID를 메모하세요. 이는 다음 단계에 필요합니다. 예를 들어, 백업 명령어가 2024-02-22 02:17:47 UTC -- Backup 1708568263_2024_02_22_16.9.0-ce is done.을 출력하면, 백업 ID는 1708568263_2024_02_22_16.9.0-ce입니다.
5. 전체 백업이 백업 버킷에 데이터를 생성했는지 확인하세요.

6. 백업 명령어를 다시 실행하고 이번에는 Git 저장소의 증분 백업 및 백업 ID를 지정하세요. 이전 단계의 예제 ID를 사용하면 명령어는 다음과 같습니다:

    sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db INCREMENTAL=yes PREVIOUS_BACKUP=1708568263_2024_02_22_16.9.0-ce
   

   PREVIOUS_BACKUP 값은 이 명령어에서 사용되지는 않지만 명령어에서 필요합니다. 이 불필요한 요구 사항을 제거하기 위한 이슈가 있습니다(issue 429141).

7. 증분 백업이 성공적으로 수행되었는지 확인하세요. 그리고 객체 저장소에 데이터가 추가되었는지 확인하세요.

8. 매일 백업을 생성하도록 cron을 구성하세요. root 사용자의 crontab을 편집하세요:

    sudo su -
    crontab -e
   

   거기에 매월 1일에 매일 새벽 2시에 백업을 스케줄하도록 다음 줄을 추가하세요. 백업을 복원하기 위해 필요한 증분의 수를 제한하기 위해 매월 1일에는 Git 저장소의 전체 백업을 수행하고 그 외 날들에는 증분 백업을 수행할 것입니다:

    0 2 1 * * /opt/gitlab/bin/gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db CRON=1
    0 2 2-31 * * /opt/gitlab/bin/gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db INCREMENTAL=yes PREVIOUS_BACKUP=1708568263_2024_02_22_16.9.0-ce CRON=1
   

구성 파일의 백업 구성

만약 구성 및 비밀은 배포 외부에서 정의되었다가 배포되는 경우, 백업 전략의 구현은 구체적인 설정 및 요구 사항에 따라 다릅니다. 예를 들어, AWS Secret Manager에 비밀을 저장하고 여러 지역으로 복제한 후 스크립트를 구성하여 비밀을 자동으로 백업할 수 있습니다.

만약 구성과 비밀이 배포 내부에서만 정의된 경우:

1. 구성 파일 저장은 구성 및 비밀 파일을 추출하는 방법에 대해 설명합니다.
2. 이러한 파일은 별도의 보다 제한적인 객체 저장소 계정에 업로드되어야 합니다.

백업 복원

GitLab 인스턴스의 백업을 복원합니다.

사전 요구 사항

백업을 복원하기 전에:

1. 작업 대상 GitLab 인스턴스를 선택.
2. 대상 GitLab 인스턴스가 AWS 백업이 저장된 지역에 있는지 확인합니다.
3. 백업 데이터가 생성된 GitLab 인스턴스와 동일한 버전 및 유형(CE 또는 EE)의 GitLab를 사용하는지 확인합니다. 예: CE 15.1.4.
4. 백업된 비밀을 대상 GitLab 인스턴스에 복원.
5. 대상 GitLab 인스턴스가 동일한 저장소 구성을 가졌는지 확인합니다. 추가 저장소는 괜찮습니다.
6. 백업된 GitLab 인스턴스에 객체 저장소에 저장된 blob이 있는 경우, 해당 종류의 blob에 대한 객체 저장소가 구성되어 있는지 확인합니다.
7. 백업된 GitLab 인스턴스에 파일 시스템에 저장된 blob이 있는 경우, NFS가 구성되어 있는지 확인합니다.

8. 새로운 비밀이나 구성을 사용하고 복원 중에 예상치 못한 구성 변경을 피하려면:

   • 모든 노드에서 Linux 패키지 설치:
     1. 대상 GitLab 인스턴스를 재구성합니다.
     2. 대상 GitLab 인스턴스를 재시작합니다.

   • Helm 차트(Kubernetes) 설치:

     1. 모든 GitLab Linux 패키지 노드에서 다음을 실행하세요:

        sudo gitlab-ctl reconfigure
        sudo gitlab-ctl start
        

     2. 차트를 배포하여 동작하는 GitLab 인스턴스가 있는지 확인하세요. 다음 명령을 실행하여 Toolbox pod이 활성화되어 있는지 확인하세요:

        kubectl get pods -lrelease=RELEASE_NAME,app=toolbox
        

     3. Webservice, Sidekiq 및 Toolbox pod를 다시 시작해야 합니다. 해당 pod를 다시 시작하는 가장 안전한 방법은 다음을 실행하는 것입니다:

        kubectl delete pods -lapp=sidekiq,release=<helm release name>
        kubectl delete pods -lapp=webservice,release=<helm release name>
        kubectl delete pods -lapp=toolbox,release=<helm release name>
        

9. 대상 GitLab 인스턴스가 여전히 작동하는지 확인합니다. 예를 들어:

   • 헬스 체크 엔드포인트에 요청을 보냅니다.
   • GitLab 체크 Rake 작업을 실행합니다.

10. PostgreSQL 데이터베이스에 연결하는 GitLab 서비스를 중지합니다.

    • 모든 Puma 또는 Sidekiq을 실행하는 노드에서 Linux 패키지 설치:

      sudo gitlab-ctl stop
      

    • Helm 차트(Kubernetes) 설치:

      1. 후속 재시작을 위해 데이터베이스 클라이언트의 현재 복제 수를 메모하세요:

         kubectl get deploy -n <namespace> -lapp=sidekiq,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
         kubectl get deploy -n <namespace> -lapp=webservice,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
         kubectl get deploy -n <namespace> -lapp=prometheus,release=<helm release name> -o jsonpath='{.items[].spec.replicas}{"\n"}'
         

      2. 복원 프로세스에 잠금이 간섭되지 않도록 데이터베이스 클라이언트를 중지합니다:

         kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=0
         kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=0
         kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=0
         

객체 저장소 데이터 복원

PostgreSQL 데이터 복원

Git 저장소 복원

복원할 노드를 선택하거나 생성하세요:

• Linux 패키지 설치의 경우, 일반적으로 Puma 또는 Sidekiq을 실행하는 노드인 Rails 노드를 선택하세요.
• Helm 차트(Kubernetes) 설치의 경우, Git 저장소 백업 노드를 구성하지 않았다면, 이제 생성하세요:
  1. 8 vCPU 및 7.2 GB 메모리가 있는 VM을 생성합니다. 이 노드는 Praefect 노드가 Git 데이터를 백업할 수 없기 때문에 Git 저장소를 백업하고 복원하는 데 사용됩니다.
  2. 노드를 참조 아키텍쳐에 정의된 대로 GitLab Rails 노드로 구성합니다. 다른 GitLab Rails 노드와 마찬가지로, 이 노드는 주 데이터베이스 및 Gitaly Cluster에 액세스해야 합니다.
  3. 대상 GitLab에 백업된 비밀을 복원하세요.

Git 저장소를 복원하려면:

1. 노드에 충분한 첨부 스토리지가 있는지 확인하세요. 이 스토리지에는 Git 저장소의 .tar 파일과 해당 데이터가 모두 저장됩니다.
2. GitLab Rails 노드에 SSH로 로그인하세요.
3. 객체 저장소 데이터 복원의 일환으로, GitLab 백업된 Git 저장소의 .tar 파일이 포함된 버킷을 복원했어야 합니다.

4. 백업된 .tar 파일을 해당하는 gitlab_rails['backup_path']로 설명된 백업 디렉터리로 다운로드하세요. 기본값은 /var/opt/gitlab/backups입니다. 백업 파일의 소유자는 git 사용자여야 합니다.

   sudo cp 11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar /var/opt/gitlab/backups/
   sudo chown git:git /var/opt/gitlab/backups/11493107454_2018_04_25_10.6.4-ce_gitlab_backup.tar
   

5. 백업을 복원하고자 하는 백업의 ID를 지정하여 복원합니다:

   경고: 복원 명령은 추가 매개변수가 필요합니다. 이는 설치에서 PgBouncer를 사용하는 경우 성능상의 이유로 또는 Patroni 클러스터와 함께 사용하는 경우에 해당합니다.

   # 이 명령은 GitLab 데이터베이스의 내용을 덮어씁니다!
   # 참고: "_gitlab_backup.tar"는 이름에서 제외됩니다
   sudo gitlab-backup restore BACKUP=11493107454_2018_04_25_10.6.4-ce
   

   백업된 tar 파일과 설치된 GitLab 버전 간에 불일치가 있는 경우, 복원 명령은 오류 메시지와 함께 중단됩니다. 올바른 GitLab 버전을 설치한 다음 다시 시도하세요.

6. GitLab을 다시 시작하고 확인하세요:
   • Linux 패키지 설치:

     1. 모든 Puma 또는 Sidekiq 노드에서 실행:

        sudo gitlab-ctl restart
        

     2. 하나의 Puma 또는 Sidekiq 노드에서 실행:

        sudo gitlab-rake gitlab:check SANITIZE=true
        

   • Helm 차트(Kubernetes) 설치:

     1. 필수 조건에 표시된 복제본 수를 사용하여 중지된 배포를 시작하세요:

        kubectl scale deploy -lapp=sidekiq,release=<helm release name> -n <namespace> --replicas=<original value>
        kubectl scale deploy -lapp=webservice,release=<helm release name> -n <namespace> --replicas=<original value>
        kubectl scale deploy -lapp=prometheus,release=<helm release name> -n <namespace> --replicas=<original value>
        

     2. Toolbox 파드에서 실행:

        sudo gitlab-rake gitlab:check SANITIZE=true
        

7. 데이터베이스 값이 현재 비밀을 사용하여 복호화될 수 있는지 확인하세요. 특히 /etc/gitlab/gitlab-secrets.json이 복원되었거나 다른 서버가 복원 대상인 경우:

   • Linux 패키지 설치의 경우, Puma 또는 Sidekiq 노드에서 실행:

     sudo gitlab-rake gitlab:doctor:secrets
     

   • Helm 차트(Kubernetes) 설치의 경우, Toolbox 파드에서 실행:

     sudo gitlab-rake gitlab:doctor:secrets
     

8. 추가적인 보증을 위해 업로드된 파일에 대한 무결성 검사를 수행할 수 있습니다:

   • Linux 패키지 설치의 경우, Puma 또는 Sidekiq 노드에서 실행:

     sudo gitlab-rake gitlab:artifacts:check
     sudo gitlab-rake gitlab:lfs:check
     sudo gitlab-rake gitlab:uploads:check
     

   • Helm 차트(Kubernetes) 설치의 경우, 이러한 명령은 모든 행을 반복하므로 시간이 오래 걸리기 때문에 GitLab Rails 노드에서 실행하세요:

     sudo gitlab-rake gitlab:artifacts:check
     sudo gitlab-rake gitlab:lfs:check
     sudo gitlab-rake gitlab:uploads:check
     

   누락되거나 손상된 파일이 발견되더라도 항상 백업 및 복원 프로세스가 실패했음을 의미하는 것은 아닙니다. 예를 들어 파일이 원본 GitLab 인스턴스에서 누락되거나 손상될 수 있습니다. 이전 백업을 교차 참조해야 할 수 있습니다. GitLab을 새 환경으로 이전하는 경우, 동일한 검사를 소스 GitLab 인스턴스에서 실행하여 무결성 검사 결과가 기존에 있는지 또는 백업 및 복원 프로세스와 관련이 있는지 확인할 수 있습니다.

복원 작업은 완료되어야 합니다.