• 매일 백업 구성
  • PostgreSQL 데이터 백업 구성
  • 객체 리포지터리 데이터 백업 구성
  • Git 리포지터리의 백업 구성
  • 설정 파일의 백업 구성
• 백업 복원
  • 사전 요구 사항
  • 개체 리포지터리 데이터 복원
  • PostgreSQL 데이터 복원
  • Git 리포지터리 복원

대형 레퍼런스 아키텍처의 백업 및 복원

이 문서에서는 다음을 설명합니다:

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

이 문서는 다음 환경을 사용하는 경우에 대해 의도되었습니다:

• Linux package (Omnibus) 및 운영 환경 하이브리드 레퍼런스 아키텍처 3,000명 이상의 사용자용
• Amazon RDS를 통한 PostgreSQL 데이터
• Amazon S3를 위한 객체 리포지터리
• 가능한 모든 것을 저장하기 위한 객체 리포지터리에서 블롭 및 컨테이너 레지스트리를 포함하여 GitLab 데이터

매일 백업 구성

PostgreSQL 데이터 백업 구성

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

객체 리포지터리 데이터 백업 구성

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

Git 리포지터리의 백업 구성

Cloud native hybrid를 사용하는 경우, GitLab Linux 패키지를 실행하는 VM을 프로비저닝하십시오.

1. 8개의 vCPU와 7.2GB 메모리를 가진 VM을 실행합니다. 이 노드는 Git 리포지터리를 백업하는 데 사용됩니다. backup-utility에 Gitaly 서버 측 백업 지원을 추가하는 것이 제안되어 있습니다. issue 438393에서 VM을 프로비저닝할 필요가 없어질 것입니다.

2. 이 노드를 귀하의 참조 아키텍처에 정의된 다른 GitLab Rails 노드처럼 구성합니다. 다른 GitLab Rails 노드와 마찬가지로, 이 노드는 주요 PostgreSQL 데이터베이스, Redis, 객체 리포지터리 및 Gitaly 클러스터에 액세스해야 합니다. Linux 패키지 설치에 대한 동등한 Helm 차트 값으로 번역해야 할 경우가 있을 수 있습니다. Praefect 노드는 Git 데이터를 백업하는 데 사용될 수 없습니다. GitLab Rails 노드여야 합니다.

3. 다음과 같이 주요 서비스를 중지하여 GitLab 애플리케이션이 이 노드에서 실행되지 않도록 합니다:

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

   • GitLab을 재구성합니다.

     sudo gitlab-ctl reconfigure
     

   • 유일하게 남아있어야 하는 서비스는 logrotate입니다. logrotate만 남아 있는지 확인하려면 다음을 실행하십시오:

     gitlab-ctl status
     

   issue 6823에서 이러한 요구 사항을 충족하는 Linux 패키지에 역할을 추가하기를 제안하고 있습니다.

Git 리포지터리를 백업하려면:

1. 모든 Gitaly 노드에서 서버 측 백업 대상을 구성.
2. 객체 리포지터리 데이터의 백업에 대한 대상 버킷을 추가.

3. Git 데이터의 전체 백업을 수행합니다. REPOSITORIES_SERVER_SIDE 변수를 사용하고 PostgreSQL 데이터를 건너뜁니다.

   sudo gitlab-backup create REPOSITORIES_SERVER_SIDE=true SKIP=db
   

   이로써 Gitaly 노드가 Git 데이터 및 일부 메타데이터를 원격 리포지터리로 업로드합니다. 업로드, 아티팩트 및 LFS와 같은 Blob은 명시적으로 건너뛰지 않아도 됩니다. 왜냐하면 gitlab-backup 명령은 기본적으로 객체 리포지터리를 백업하지 않기 때문입니다.

4. 백업의 백업 ID를 기록합니다. 이 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
   

9. 거기에 다음 줄을 추가하여 매월 첫째 날에 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 인스턴스에 개체 리포지터리에 저장된 블롭이 있으면, 해당 유형의 블롭에 대해 개체 리포지터리가 구성되어 있는지 확인합니다.
7. 백업된 GitLab 인스턴스에 파일 시스템에 저장된 블롭이 있으면, 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 인스턴스가 여전히 작동하는지 확인합니다. 예:
   • health check endpoints에 요청을 보냅니다.
   • GitLab check Rake tasks를 실행합니다.
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.2GB 메모리가 있는 VM을 실행하세요. Praefect 노드가 Git 데이터를 백업하는 데 사용되지 않기 때문에 이 노드는 Git 리포지터리를 백업하고 복원하는 데 사용됩니다 (참고 사항).
  2. 노드를 귀사의 참조 아키텍처에 정의된 다른 GitLab Rails 노드로 구성하세요. 이 노드도 다른 GitLab Rails 노드와 마찬가지로 주 PostgreSQL 데이터베이스 및 Gitaly 클러스터에 액세스해야 합니다.
  3. 백업된 시크릿을 대상 GitLab에 복원하세요.

Git 리포지터리를 복원하려면:

1. 노드에는 Git 리포지터리의 .tar 파일 및 해당 추출된 데이터를 저장할 수 있는 충분한 첨부 리포지터리가 있는지 확인하세요.
2. GitLab Rails 노드로 SSH를 실행하세요.
3. 객체 리포지터리 데이터 복원의 일환으로 GitLab 백업 .tar 파일이 포함된 버킷을 복원했어야 합니다.

4. 백업 .tar 파일을 gitlab.rb 구성 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. 복원할 백업을 지정하여 백업을 복원하세요:

   복원 명령에는 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. Prerequisites에 기록된 복제본 수를 사용하여 중지된 배포를 시작하세요:

        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 pod에서 실행하세요:

        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 pod에서 실행하세요:

     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) 설치의 경우, 이러한 명령은 모든 행을 반복하기 때문에 시간이 오래 걸릴 수 있습니다. 이를 고려하여 Toolbox pod이 아닌 GitLab Rails 노드에서 다음 명령을 실행하세요.

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

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

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